incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: [PROPOSAL][VOTE] Subversion
Date Fri, 06 Nov 2009 19:15:31 GMT
On Fri, Nov 6, 2009 at 10:43 AM, Greg Stein <> wrote:
> On Thu, Nov 5, 2009 at 12:48, Martijn Dashorst
> <> wrote:
>> On Thu, Nov 5, 2009 at 5:20 PM, Greg Stein <> 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:
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message