Re: [PROPOSAL][VOTE] Subversion

View: New views
15 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Nov 5, 2009 at 12:48, Martijn Dashorst
<martijn.dashorst@...> wrote:

> On Thu, Nov 5, 2009 at 5:20 PM, Greg Stein <gstein@...> wrote:
>> I do not expect Subversion to make a release while in Incubation. Our
>> next big release is 1.7, and is expected in (hopefully?) Q1 next year.
>> There is a chance that we'd like to release 1.6.7 while we're
>> incubating. That can be a bridge to cross later.
>
> While I have great confidence in the ability of the subversion team to
> build quality and legally sound releases, I do think that doing one
> release inside the incubator would be prudent. If only to ensure due
> process. In my opinion getting a release vetted by the IPMC is one of
> the hardest things to accomplish and diversity aside the most
> important aspect of a successful incubation.

You can read about Subversion's release process here:
  http://subversion.tigris.org/release-process.html

I will posit that it uses a process that exceeds that performed by
most Apache projects. I hear what you're saying, but will point out
that svn has SEVEN Members of the ASF(*) on its equivalent of a PMC.
There is more than ample experience with how the ASF produces
releases.

But with all that said, how about we do this: we'll do a 1.6.7 release
from the 1.6.x branch after we do the code import. That release will
be performed by svncorp (we don't want to touch every file on that
branch to relicense it, and to switch file headers). The release
process can be followed/tracked by the Incubator PMC. I'll make sure
to relay pointers to all relevant threads as the release is performed.

Here are some relevant mail messages from the 1.6.6 release process,
so you'll know what to expect for 1.6.7:

Initial announcement for release-process-start (Sep 28):
  http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2401346

Call for testing/signatures of the release tarball (Oct 15):
  http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407947

Release announcement (Oct 21):
  http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410047


I believe the primary difference will be installing the release
tarball onto dist.apache.org and its mirroring system (in addition to
subversion.tigris.org). Third parties who produce precompiled binaries
may continue to do so, but can fetch their tarballs from the new
location.

Note: we may want to load all the old releases onto
archive.apache.org. Infra is fine with this, but that decision hasn't
been made by the project yet.


After the code import, we'll switch trunk over to the ASF standard
header (our files have the same header, but s/ASF/svncorp/). The trunk
will then be ready for 1.7 release as an ASF-branded project.


Any thoughts or concerns?

Cheers,
-g

(*) the ASF Members are: gstein, jorton, fitz, jerenkrantz, striker, rooneg, dlr

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415190

Re: [PROPOSAL][VOTE] Subversion

by Branko Cibej :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Greg Stein wrote:
> After the code import, we'll switch trunk over to the ASF standard
> header (our files have the same header, but s/ASF/svncorp/). The trunk
> will then be ready for 1.7 release as an ASF-branded project.
>
>
> Any thoughts or concerns?
>  

Just one. Once 1.7 is ASF-branded, all is dandy for that version and
newer ones. However, we're still bound to support 1.6, and security
fixes for 1.5. That means we'll have to rebrand those two branches
anyway, won't we? Might as well do that for 1.6.7 then ...

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415195

Re: [PROPOSAL][VOTE] Subversion

by Justin Erenkrantz-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 10:56 AM, Branko Cibej <brane@...> wrote:
>> Any thoughts or concerns?
>
> Just one. Once 1.7 is ASF-branded, all is dandy for that version and
> newer ones. However, we're still bound to support 1.6, and security
> fixes for 1.5. That means we'll have to rebrand those two branches
> anyway, won't we? Might as well do that for 1.6.7 then ...

As we discussed at the Meetup last night, changing all of the
attributions and such would be a bit disruptive for a point release.
So, I'd prefer that we not rebrand to minimize the delta between 1.6.6
and 1.6.7 (and for 1.5.x).

My $.02.  -- justin

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415199

Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 13:56, Branko Čibej <brane@...> wrote:

> Greg Stein wrote:
>> After the code import, we'll switch trunk over to the ASF standard
>> header (our files have the same header, but s/ASF/svncorp/). The trunk
>> will then be ready for 1.7 release as an ASF-branded project.
>>
>>
>> Any thoughts or concerns?
>
> Just one. Once 1.7 is ASF-branded, all is dandy for that version and
> newer ones. However, we're still bound to support 1.6, and security
> fixes for 1.5. That means we'll have to rebrand those two branches
> anyway, won't we? Might as well do that for 1.6.7 then ...

I'm not sure, to be honest. There ought to be precedent for it that we can find.

And I'd rather not do the rebranding for 1.6.7 until we figure out the
long-term plan.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415201

Re: [PROPOSAL][VOTE] Subversion

by Justin Erenkrantz-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 10:43 AM, Greg Stein <gstein@...> wrote:

> On Thu, Nov 5, 2009 at 12:48, Martijn Dashorst
> <martijn.dashorst@...> wrote:
>> On Thu, Nov 5, 2009 at 5:20 PM, Greg Stein <gstein@...> wrote:
>>> I do not expect Subversion to make a release while in Incubation. Our
>>> next big release is 1.7, and is expected in (hopefully?) Q1 next year.
>>> There is a chance that we'd like to release 1.6.7 while we're
>>> incubating. That can be a bridge to cross later.
>>
>> While I have great confidence in the ability of the subversion team to
>> build quality and legally sound releases, I do think that doing one
>> release inside the incubator would be prudent. If only to ensure due
>> process. In my opinion getting a release vetted by the IPMC is one of
>> the hardest things to accomplish and diversity aside the most
>> important aspect of a successful incubation.
>
> You can read about Subversion's release process here:
>  http://subversion.tigris.org/release-process.html
>
> I will posit that it uses a process that exceeds that performed by
> most Apache projects. I hear what you're saying, but will point out
> that svn has SEVEN Members of the ASF(*) on its equivalent of a PMC.
> There is more than ample experience with how the ASF produces
> releases.

Yes, there was a lot of interplay between APR, HTTP Server, and
Subversion on their release processes.

Due to SVN's use of digital signatures and requiring 3 +1s *per
platform*, I have zero qualms about the release process that SVN uses
- it exceeds Apache's minimum requirements by far.

> But with all that said, how about we do this: we'll do a 1.6.7 release
> from the 1.6.x branch after we do the code import. That release will
> be performed by svncorp (we don't want to touch every file on that
> branch to relicense it, and to switch file headers). The release
> process can be followed/tracked by the Incubator PMC. I'll make sure
> to relay pointers to all relevant threads as the release is performed.

+1.  I think this is a fair compromise.  -- justin

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415205

Re: [PROPOSAL][VOTE] Subversion

by Branko Cibej :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Justin Erenkrantz wrote:

> On Fri, Nov 6, 2009 at 10:56 AM, Branko Cibej <brane@...> wrote:
>  
>>> Any thoughts or concerns?
>>>      
>> Just one. Once 1.7 is ASF-branded, all is dandy for that version and
>> newer ones. However, we're still bound to support 1.6, and security
>> fixes for 1.5. That means we'll have to rebrand those two branches
>> anyway, won't we? Might as well do that for 1.6.7 then ...
>>    
>
> As we discussed at the Meetup last night, changing all of the
> attributions and such would be a bit disruptive for a point release.
> So, I'd prefer that we not rebrand to minimize the delta between 1.6.6
> and 1.6.7 (and for 1.5.x).
>
> My $.02.  -- justin
>  
Oh, I agree -- otherwise backports will be a royal pain. So hopefully we
won't have to rebrand point releases and security fixes.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415206

Re: [PROPOSAL][VOTE] Subversion

by Craig L Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov 6, 2009, at 10:43 AM, Greg Stein wrote:

> But with all that said, how about we do this: we'll do a 1.6.7 release
> from the 1.6.x branch after we do the code import. That release will
> be performed by svncorp (we don't want to touch every file on that
> branch to relicense it, and to switch file headers). The release
> process can be followed/tracked by the Incubator PMC. I'll make sure
> to relay pointers to all relevant threads as the release is performed.
>
I don't think that releasing svn by svncorp without any Apache license  
proves anything except that they can make a release after moving the  
repository. So if it makes anyone happy, fine. But it's not an Apache  
release.

I'd be interested in seeing a release after it's been licensed to  
Apache and has all of the Apache license, notice, and packaging.

Craig

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415208

smime.p7s (3K) Download Attachment

Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 14:21, Craig L Russell <Craig.Russell@...> wrote:

>
> On Nov 6, 2009, at 10:43 AM, Greg Stein wrote:
>
>> But with all that said, how about we do this: we'll do a 1.6.7 release
>> from the 1.6.x branch after we do the code import. That release will
>> be performed by svncorp (we don't want to touch every file on that
>> branch to relicense it, and to switch file headers). The release
>> process can be followed/tracked by the Incubator PMC. I'll make sure
>> to relay pointers to all relevant threads as the release is performed.
>>
> I don't think that releasing svn by svncorp without any Apache license
> proves anything except that they can make a release after moving the
> repository. So if it makes anyone happy, fine. But it's not an Apache
> release.
>
> I'd be interested in seeing a release after it's been licensed to Apache and
> has all of the Apache license, notice, and packaging.

It already has the Apache License (v2), and it uses a NOTICE file (per
the license), and our packaging is tighter/stronger than typical
Apache releases (per Justin's note). Are there other items to an
"Apache release" that are needed to demonstrate that the svn project
understands the proper release process?

The 1.7 release is not on the schedule at all, while we're going to do
a 1.6.7 release in a few weeks.

We're naturally very reticent to disrupt a prior-release branch with a
massive relicense.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415213

Re: [PROPOSAL][VOTE] Subversion

by Craig L Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Greg,

On Nov 6, 2009, at 11:30 AM, Greg Stein wrote:

> On Fri, Nov 6, 2009 at 14:21, Craig L Russell  
> <Craig.Russell@...> wrote:
>>
>> On Nov 6, 2009, at 10:43 AM, Greg Stein wrote:
>>
>>> But with all that said, how about we do this: we'll do a 1.6.7  
>>> release
>>> from the 1.6.x branch after we do the code import. That release will
>>> be performed by svncorp (we don't want to touch every file on that
>>> branch to relicense it, and to switch file headers). The release
>>> process can be followed/tracked by the Incubator PMC. I'll make sure
>>> to relay pointers to all relevant threads as the release is  
>>> performed.
>>>
>> I don't think that releasing svn by svncorp without any Apache  
>> license
>> proves anything except that they can make a release after moving the
>> repository. So if it makes anyone happy, fine. But it's not an Apache
>> release.
>>
>> I'd be interested in seeing a release after it's been licensed to  
>> Apache and
>> has all of the Apache license, notice, and packaging.
>
> It already has the Apache License (v2), and it uses a NOTICE file (per
> the license), and our packaging is tighter/stronger than typical
> Apache releases (per Justin's note). Are there other items to an
> "Apache release" that are needed to demonstrate that the svn project
> understands the proper release process?
I guess I don't understand your comment here:

>>> (we don't want to touch every file on that
>>> branch to relicense it, and to switch file headers).

That sounds like your plan is to relicense, or am I misreading you?

Craig

>
> The 1.7 release is not on the schedule at all, while we're going to do
> a 1.6.7 release in a few weeks.
>
> We're naturally very reticent to disrupt a prior-release branch with a
> massive relicense.
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415215

smime.p7s (3K) Download Attachment

Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 14:36, Craig L Russell <Craig.Russell@...> wrote:

> Hi Greg,
>
> On Nov 6, 2009, at 11:30 AM, Greg Stein wrote:
>
>> On Fri, Nov 6, 2009 at 14:21, Craig L Russell <Craig.Russell@...>
>> wrote:
>>>
>>> On Nov 6, 2009, at 10:43 AM, Greg Stein wrote:
>>>
>>>> But with all that said, how about we do this: we'll do a 1.6.7 release
>>>> from the 1.6.x branch after we do the code import. That release will
>>>> be performed by svncorp (we don't want to touch every file on that
>>>> branch to relicense it, and to switch file headers). The release
>>>> process can be followed/tracked by the Incubator PMC. I'll make sure
>>>> to relay pointers to all relevant threads as the release is performed.
>>>>
>>> I don't think that releasing svn by svncorp without any Apache license
>>> proves anything except that they can make a release after moving the
>>> repository. So if it makes anyone happy, fine. But it's not an Apache
>>> release.
>>>
>>> I'd be interested in seeing a release after it's been licensed to Apache
>>> and
>>> has all of the Apache license, notice, and packaging.
>>
>> It already has the Apache License (v2), and it uses a NOTICE file (per
>> the license), and our packaging is tighter/stronger than typical
>> Apache releases (per Justin's note). Are there other items to an
>> "Apache release" that are needed to demonstrate that the svn project
>> understands the proper release process?
>
> I guess I don't understand your comment here:
>
>>>> (we don't want to touch every file on that
>>>> branch to relicense it, and to switch file headers).
>
> That sounds like your plan is to relicense, or am I misreading you?

All of the existing tags/branches of svn use a tweaked Apache Software
License, v1.1, and generally have a file header claims a copyright by
CollabNet.

trunk is licensed under Apache License, v2, and has a file header as
defined by the Apache Legal Affairs Committee, though with SVNCorp
rather than ASF as the rights-holder to the distribution. After we
import the codebase, we intend to tweak all of the file headers on
trunk with s/SVNCorp/ASF/.


Now... if we were to make a release from one of those branches, then I
believe we would need to relicense and rewrite all of their file
headers before making that release. That is a lot of disruption for
what is supposed to be a patch release.

The Subversion project has a policy to support the prior release, and
to provide security fixes for the release before that. Today, that is
1.6.x and 1.5.x, respectively. I honestly don't know how we're going
to make those point releases, but gotta believe there is existing
precedent. Right *now*, svncorp is still around and can make that
1.6.7 release. Six months from now? Dunno.


Does that clarify my message?

Thanks,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415221

Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 14:44, Greg Stein <gstein@...> wrote:

>...
> All of the existing tags/branches of svn use a tweaked Apache Software
> License, v1.1, and generally have a file header claims a copyright by
> CollabNet.
>
> trunk is licensed under Apache License, v2, and has a file header as
> defined by the Apache Legal Affairs Committee, though with SVNCorp
> rather than ASF as the rights-holder to the distribution. After we
> import the codebase, we intend to tweak all of the file headers on
> trunk with s/SVNCorp/ASF/.

To clarify this further: I believe that a release from *trunk* matches
a standard Apache release.

From branches... not precisely, but we can demonstrate that (with the
caveat of file contents), our *process* follows/exceeds Apache
guidelines.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415223

Re: [PROPOSAL][VOTE] Subversion

by Craig L Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov 6, 2009, at 11:44 AM, Greg Stein wrote:

> On Fri, Nov 6, 2009 at 14:36, Craig L Russell  
> <Craig.Russell@...> wrote:
>> Hi Greg,
>>
>> On Nov 6, 2009, at 11:30 AM, Greg Stein wrote:
>>
>>> On Fri, Nov 6, 2009 at 14:21, Craig L Russell  
>>> <Craig.Russell@...>
>>> wrote:
>>>>
>>>> On Nov 6, 2009, at 10:43 AM, Greg Stein wrote:
>>>>
>>>>> But with all that said, how about we do this: we'll do a 1.6.7  
>>>>> release
>>>>> from the 1.6.x branch after we do the code import. That release  
>>>>> will
>>>>> be performed by svncorp (we don't want to touch every file on that
>>>>> branch to relicense it, and to switch file headers). The release
>>>>> process can be followed/tracked by the Incubator PMC. I'll make  
>>>>> sure
>>>>> to relay pointers to all relevant threads as the release is  
>>>>> performed.
>>>>>
>>>> I don't think that releasing svn by svncorp without any Apache  
>>>> license
>>>> proves anything except that they can make a release after moving  
>>>> the
>>>> repository. So if it makes anyone happy, fine. But it's not an  
>>>> Apache
>>>> release.
>>>>
>>>> I'd be interested in seeing a release after it's been licensed to  
>>>> Apache
>>>> and
>>>> has all of the Apache license, notice, and packaging.
>>>
>>> It already has the Apache License (v2), and it uses a NOTICE file  
>>> (per
>>> the license), and our packaging is tighter/stronger than typical
>>> Apache releases (per Justin's note). Are there other items to an
>>> "Apache release" that are needed to demonstrate that the svn project
>>> understands the proper release process?
>>
>> I guess I don't understand your comment here:
>>
>>>>> (we don't want to touch every file on that
>>>>> branch to relicense it, and to switch file headers).
>>
>> That sounds like your plan is to relicense, or am I misreading you?
>
> All of the existing tags/branches of svn use a tweaked Apache Software
> License, v1.1, and generally have a file header claims a copyright by
> CollabNet.
>
> trunk is licensed under Apache License, v2, and has a file header as
> defined by the Apache Legal Affairs Committee, though with SVNCorp
> rather than ASF as the rights-holder to the distribution. After we
> import the codebase, we intend to tweak all of the file headers on
> trunk with s/SVNCorp/ASF/.
>
>
> Now... if we were to make a release from one of those branches, then I
> believe we would need to relicense and rewrite all of their file
> headers before making that release. That is a lot of disruption for
> what is supposed to be a patch release.
>
> The Subversion project has a policy to support the prior release, and
> to provide security fixes for the release before that. Today, that is
> 1.6.x and 1.5.x, respectively. I honestly don't know how we're going
> to make those point releases, but gotta believe there is existing
> precedent. Right *now*, svncorp is still around and can make that
> 1.6.7 release. Six months from now? Dunno.
For my money, I'd prefer to see a real Apache release with the real  
copyright notices and licenses that the project intends to ship.

Perhaps make an alpha 1.7 from the trunk? Doesn't even need to work  
perfectly, since the process to make sure a release works is already  
known.

We have required every incubating project for the last few years to  
make a release before graduation.

Craig

>
>
> Does that clarify my message?
>
> Thanks,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415296

smime.p7s (3K) Download Attachment

Parent Message unknown Re: [PROPOSAL][VOTE] Subversion

by Greg Stein-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

[Sorry for brevity; phone]

We're not ready for an alpha, but we could do an "internal" experimental release. I seem to recall seeing that in the docs.

How about that?

On Nov 6, 2009 3:50 PM, "Craig L Russell" <Craig.Russell@...> wrote:

On Nov 6, 2009, at 11:44 AM, Greg Stein wrote: > On Fri, Nov 6, 2009 at 14:36, Craig L Russell <Cr...

For my money, I'd prefer to see a real Apache release with the real copyright notices and licenses that the project intends to ship.

Perhaps make an alpha 1.7 from the trunk? Doesn't even need to work perfectly, since the process to make sure a release works is already known.

We have required every incubating project for the last few years to make a release before graduation.

Craig

> > > > Does that clarify my message? > > Thanks, > -g >

> --------------------------------------------------------------------- > To unsubscribe, e-mail: ge...

Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:...


Re: [PROPOSAL][VOTE] Subversion

by Craig L Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov 6, 2009, at 4:07 PM, Greg Stein wrote:

> [Sorry for brevity; phone]
>
> We're not ready for an alpha, but we could do an "internal"  
> experimental
> release. I seem to recall seeing that in the docs.

+1

As I thought I said earlier, *any* release that has proper Apache  
packaging, licensing, and notices is fine with me. We've had this  
discussion in the incubator before, for similar reasons, and I think  
there is consensus that a formal review of a podling release is a  
reasonable gate for graduation. No one needs to believe that the  
release is stable, tested, reliable, etc.; it just needs to be reviewed.

Craig

>
> How about that?
>
> On Nov 6, 2009 3:50 PM, "Craig L Russell" <Craig.Russell@...>  
> wrote:
>
> On Nov 6, 2009, at 11:44 AM, Greg Stein wrote: > On Fri, Nov 6, 2009  
> at
> 14:36, Craig L Russell <Cr...
> For my money, I'd prefer to see a real Apache release with the real
> copyright notices and licenses that the project intends to ship.
>
> Perhaps make an alpha 1.7 from the trunk? Doesn't even need to work
> perfectly, since the process to make sure a release works is already  
> known.
>
> We have required every incubating project for the last few years to  
> make a
> release before graduation.
>
> Craig
>
>>>>>> Does that clarify my message? > > Thanks, > -g >
>>
>>> --------------------------------------------------------------------- >
>> To unsubscribe, e-mail: ge...
>>
> Craig L Russell Architect, Sun Java Enterprise System
> http://db.apache.org/jdo 408 276-5638 mailto:...
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415311

smime.p7s (3K) Download Attachment

Re: [PROPOSAL][VOTE] Subversion

by Leo Simons :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 7:46 PM, Greg Stein <gstein@...> wrote:

> On Fri, Nov 6, 2009 at 14:44, Greg Stein <gstein@...> wrote:
>> All of the existing tags/branches of svn use a tweaked Apache Software
>> License, v1.1, and generally have a file header claims a copyright by
>> CollabNet.
>>
>> trunk is licensed under Apache License, v2, and has a file header as
>> defined by the Apache Legal Affairs Committee, though with SVNCorp
>> rather than ASF as the rights-holder to the distribution. After we
>> import the codebase, we intend to tweak all of the file headers on
>> trunk with s/SVNCorp/ASF/.
>
> To clarify this further: I believe that a release from *trunk* matches
> a standard Apache release.

Well, at the moment, probably not quite. In particular, the incubator
PMC is (in)famous for being very nitpicky (err, careful) about
licensing stuff, it's an "enlightening" experience to go through I
would say. You might want to have some fun with RAT:
http://incubator.apache.org/rat/

It finds things like this:

* No license header (some examples):
  ./subversion/bindings/swig/ruby/svn/core.rb
  ./tools/bdb/svnfs.py
  ./tools/client-side/server-version.py

* GPL license header (I understand why, but, ugh):
  ./build/config.guess

(and some 600 other complaints most of which are readily ignorable).
The various tools and scripts that say stuff like "released under the
same license as subversion" could probably do with a little attention
as well.

AIUI it from reading dist.sh those files would go into the released
tarball (I didn't attempt to actually run dist.sh, that'd take me too
much time to try and do properly).

Oh and according to what I read the other day on legal-discuss@... the
reference to the license details about the python bindings probably
ought to belong in the LICENSE file not in the NOTICE file.

On Sat, Nov 7, 2009 at 12:07 AM, Greg Stein <gstein@...> wrote:
> We're not ready for an alpha, but we could do an "internal" experimental
> release. I seem to recall seeing that in the docs.
>
> How about that?

Sure :)


ciao,


Leo

PS: +1 to start incubation obviously. The record is 2 weeks set for
MerlinDeveloper back in 2003...you have 9 days left to try and beat it
:)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415636