[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "... first release candidate is expected in August 2011." Really?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 23 May 2011 17:03:29 -0400

On 05/23/2011 04:27 PM, Greg Stein wrote:
> On Mon, May 23, 2011 at 14:51, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> On Mon, May 23, 2011 at 11:48 AM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
>>> On 05/23/2011 02:25 PM, Hyrum K Wright wrote:
>>>> The outcome of the hackathon was "we'll start alpha releases in June and
>>>> branch when the blockers are gone"
>>> Hrm... that's not quite what I recall. But then, I remained somewhat
>>> under-rested for the duration of the trip. :-)
>>> Our discussion of the default ra-dav implementation for 1.7.0 implied that
>>> there could be open "blocker" issues even after we branch. (Because if any
>>> of those blockers were serf-ish, that was our signal to restore ra_neon as
>>> the default.) I hate to fuss over such fine details, but I believe we owe
>>> it to ourselves to be clear on this general matter of branching.
>> My recollection is that we essentially said that if there are blocking
>> ra_serf issues when all the other blockers are gone, we'd flip back to
>> ra_neon for the release. (So in a sense, the ra_serf blockers aren't really
>> blockers at all.)
> Right.
> All non-serf blockers should be fixed before we branch. IOW, we get as
> close to a release candidate as possible on trunk. (and if people want
> to code new features, they should HIGHLY CONSIDER doing that on a
> branch, for later reintegration).

Should we, then, move the Serf issues to 1.7-consider in the tracker?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Received on 2011-05-23 23:03:57 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.