You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@hyrumwright.org> on 2011/07/12 16:42:35 UTC
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato <cm...@collab.net> wrote:
> The issue tracker currently has *no* non-Serf-related blocker issues open.
> Per prior agreement, this effectively means that there are no known
> blockers, as we have a contingency plan for Serf already (un-default it). I
> realize that we'd like to see the tracker sit quiet (blocker-wise) for a
> week or so before saying "ship the RC", but I think we need to face some
> realities:
>
> - blocker-class bugs can -- and will -- crop up after we branch.
>
> - blocker-class bugs can -- and will -- crop up after we release,
> for that matter!
>
> - there seems to be more dev activity on 1.8-aimed feature branches
> than on the trunk. Our "merge pain" threshold has shifted.
>
> So, with all of this in mind, I propose that we immediately branch 1.7.x and
> release beta-1. We than allow an extra week before we fire off RC1 -- we
> need to ensure that CHANGES and any other release administrivia get wrapped
> up anyway.
>
> What to do about Serf? I'd like to think that Greg could wrap up his work
> on the single remaining blocking issue in the next week or so. I've already
> heard (via Hyrum) that he's essentially finished with the work, and just
> testing his changes at this point. I do not know, though, what the status
> of the Serf 1.0 release is, which I *thought* was also a pre-requisite for
> making available many of the recent blocker-related fixes. (Greg?)
>
> Anyway, I'm *not* proposing that we immediately revert to Neon as the
> default after branching. That week of beta gives Greg (or whoever) one last
> chance to save the day for Serf. But I strongly feel that we as a community
> need to declare an RC1 date and stick with it in the absence of absolutely
> critical failures in Subversion. The fuzzy release date thing is great for
> the first, oh, two years of a release. But let's get on with it, already.
>
> So, to clarify, I'm proposing the following:
>
> * Branch 1.7.x now.
> * Release beta-1 immediately after branching.
> * Make a go/no-go call on Serf 7 days from now.
> * Release rc-1 after making (and acting on, if necessary) the Serf
> go/no-go call.
>
> What say we?
I agree with the above.
One question that I have is regarding housekeeping. Do we have any
actions which should be done on trunk (file renames, whitespace
cleaning, mergeinfo pruning, etc), which will improve our experience
when merging to the branch?
-Hyrum
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/12/2011 02:46 PM, Blair Zajac wrote:
>
> On Jul 12, 2011, at 7:42 AM, Hyrum K Wright wrote:
>
>> One question that I have is regarding housekeeping. Do we have any
>> actions which should be done on trunk (file renames, whitespace
>> cleaning, mergeinfo pruning, etc), which will improve our experience
>> when merging to the branch?
>
> I took my OCD pass through the code :)
Yay! I love to see others who are commited^H^Hted to accurate spelling.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by Blair Zajac <bl...@orcaware.com>.
On Jul 12, 2011, at 7:42 AM, Hyrum K Wright wrote:
> One question that I have is regarding housekeeping. Do we have any
> actions which should be done on trunk (file renames, whitespace
> cleaning, mergeinfo pruning, etc), which will improve our experience
> when merging to the branch?
I took my OCD pass through the code :)
Blair
RE: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by Bob Archer <Bo...@amsi.com>.
> On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright
> <hy...@hyrumwright.org> wrote:
>
> > Because I'm a nice guy (and to allow people time to comment),
> I'll
> > wait until tomorrow morning to create the branch, but plan on it
> then.
>
> +1
Is that a +1 that Hyrum is a nice guy, or that he will wait, or that he should branch?
BOb
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> Because I'm a nice guy (and to allow people time to comment), I'll
> wait until tomorrow morning to create the branch, but plan on it then.
+1
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Tue, Jul 12, 2011 at 9:42 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> The issue tracker currently has *no* non-Serf-related blocker issues open.
>>> Per prior agreement, this effectively means that there are no known
>>> blockers, as we have a contingency plan for Serf already (un-default it). I
>>> realize that we'd like to see the tracker sit quiet (blocker-wise) for a
>>> week or so before saying "ship the RC", but I think we need to face some
>>> realities:
>>>
>>> - blocker-class bugs can -- and will -- crop up after we branch.
>>>
>>> - blocker-class bugs can -- and will -- crop up after we release,
>>> for that matter!
>>>
>>> - there seems to be more dev activity on 1.8-aimed feature branches
>>> than on the trunk. Our "merge pain" threshold has shifted.
>>>
>>> So, with all of this in mind, I propose that we immediately branch 1.7.x and
>>> release beta-1. We than allow an extra week before we fire off RC1 -- we
>>> need to ensure that CHANGES and any other release administrivia get wrapped
>>> up anyway.
>>>
>>> What to do about Serf? I'd like to think that Greg could wrap up his work
>>> on the single remaining blocking issue in the next week or so. I've already
>>> heard (via Hyrum) that he's essentially finished with the work, and just
>>> testing his changes at this point. I do not know, though, what the status
>>> of the Serf 1.0 release is, which I *thought* was also a pre-requisite for
>>> making available many of the recent blocker-related fixes. (Greg?)
>>>
>>> Anyway, I'm *not* proposing that we immediately revert to Neon as the
>>> default after branching. That week of beta gives Greg (or whoever) one last
>>> chance to save the day for Serf. But I strongly feel that we as a community
>>> need to declare an RC1 date and stick with it in the absence of absolutely
>>> critical failures in Subversion. The fuzzy release date thing is great for
>>> the first, oh, two years of a release. But let's get on with it, already.
>>>
>>> So, to clarify, I'm proposing the following:
>>>
>>> * Branch 1.7.x now.
>>> * Release beta-1 immediately after branching.
>>> * Make a go/no-go call on Serf 7 days from now.
>>> * Release rc-1 after making (and acting on, if necessary) the Serf
>>> go/no-go call.
>>>
>>> What say we?
>>
>> I agree with the above.
>>
>> One question that I have is regarding housekeeping. Do we have any
>> actions which should be done on trunk (file renames, whitespace
>> cleaning, mergeinfo pruning, etc), which will improve our experience
>> when merging to the branch?
>
> Because I'm a nice guy (and to allow people time to comment), I'll
> wait until tomorrow morning to create the branch, but plan on it then.
+1 on branching tomorrow. Undecided on whether Hyrum is a nice guy :-P
Re: [PROPOSAL] Create the 1.7.x branch. Like, now.
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Jul 12, 2011 at 9:42 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> The issue tracker currently has *no* non-Serf-related blocker issues open.
>> Per prior agreement, this effectively means that there are no known
>> blockers, as we have a contingency plan for Serf already (un-default it). I
>> realize that we'd like to see the tracker sit quiet (blocker-wise) for a
>> week or so before saying "ship the RC", but I think we need to face some
>> realities:
>>
>> - blocker-class bugs can -- and will -- crop up after we branch.
>>
>> - blocker-class bugs can -- and will -- crop up after we release,
>> for that matter!
>>
>> - there seems to be more dev activity on 1.8-aimed feature branches
>> than on the trunk. Our "merge pain" threshold has shifted.
>>
>> So, with all of this in mind, I propose that we immediately branch 1.7.x and
>> release beta-1. We than allow an extra week before we fire off RC1 -- we
>> need to ensure that CHANGES and any other release administrivia get wrapped
>> up anyway.
>>
>> What to do about Serf? I'd like to think that Greg could wrap up his work
>> on the single remaining blocking issue in the next week or so. I've already
>> heard (via Hyrum) that he's essentially finished with the work, and just
>> testing his changes at this point. I do not know, though, what the status
>> of the Serf 1.0 release is, which I *thought* was also a pre-requisite for
>> making available many of the recent blocker-related fixes. (Greg?)
>>
>> Anyway, I'm *not* proposing that we immediately revert to Neon as the
>> default after branching. That week of beta gives Greg (or whoever) one last
>> chance to save the day for Serf. But I strongly feel that we as a community
>> need to declare an RC1 date and stick with it in the absence of absolutely
>> critical failures in Subversion. The fuzzy release date thing is great for
>> the first, oh, two years of a release. But let's get on with it, already.
>>
>> So, to clarify, I'm proposing the following:
>>
>> * Branch 1.7.x now.
>> * Release beta-1 immediately after branching.
>> * Make a go/no-go call on Serf 7 days from now.
>> * Release rc-1 after making (and acting on, if necessary) the Serf
>> go/no-go call.
>>
>> What say we?
>
> I agree with the above.
>
> One question that I have is regarding housekeeping. Do we have any
> actions which should be done on trunk (file renames, whitespace
> cleaning, mergeinfo pruning, etc), which will improve our experience
> when merging to the branch?
Because I'm a nice guy (and to allow people time to comment), I'll
wait until tomorrow morning to create the branch, but plan on it then.
-Hyrum