|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: [PROPOSAL][VOTE] SubversionGreg 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] SubversionOn 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] SubversionOn 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] SubversionOn 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] SubversionJustin 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 > 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] SubversionOn 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 |
|
|
Re: [PROPOSAL][VOTE] SubversionOn 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] SubversionHi 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? >>> (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@... > 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 |
|
|
Re: [PROPOSAL][VOTE] SubversionOn 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] SubversionOn 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] SubversionOn 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. 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@... > 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 |
|
|
|
|
|
Re: [PROPOSAL][VOTE] SubversionOn 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:... 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 |
|
|
Re: [PROPOSAL][VOTE] SubversionOn 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 |
| Free embeddable forum powered by Nabble | Forum Help |