zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject Re: pushing the 3.3.3 bugs
Date Wed, 26 Jan 2011 20:39:15 GMT
this is an interesting read. i'm not a big fan of the even odd numbering 
scheme. i'm also unclear how it work. for example, lets say i signed up 
to be the RM for 3.4.0. i branch, stabilize the code, and then do a 
release. would i also be in charge of 3.4.1? i would hope the answer 
would be yes. i think the RM should have some long term commitment until 
they decide to retire the 3.4 series.

it would allow things to flow a bit better if the RM pulled patches from 
trunk rather than contributors having to work with two versions of code 
to do a patch. of course that puts more work on the RM.


On 01/26/2011 11:30 AM, Patrick Hunt wrote:
> FYI, this is a _really_ good read, perhaps we should try something like
> this, at the very least we should document our approach:
> http://httpd.apache.org/dev/release.html
> <http://httpd.apache.org/dev/release.html>Patrick
> On Wed, Jan 26, 2011 at 11:23 AM, Patrick Hunt<phunt@apache.org>  wrote:
>> One other thing to keep in mind with this model. The RM is responsible for
>> backporting (or working with the author to backport) any issues that go into
>> a fix release. Today we require authors to provide patches for both the fix
>> branch and the trunk (for fixes). If changes are committed to the trunk, and
>> at some point a RM steps up to create a fix release, those changes need to
>> be applied to the fix branch. Granted, this seems to fit well with Ben's
>> original suggestion of limiting the number of fixes that go into fix
>> releases. It's a step away from what our users have come to expect though -
>> that we essentially maintain a fix release branch with most/all fixes, as
>> well as a new feature development branch (trunk).
>> Patrick
>> On Wed, Jan 26, 2011 at 11:15 AM, Patrick Hunt<phunt@apache.org>  wrote:
>>> On Wed, Jan 26, 2011 at 10:38 AM, Flavio Junqueira<fpj@yahoo-inc.com>wrote:
>>>> Ben, Your proposal in general sounds reasonable to me with the exception
>>>> of "do a release from just a branch if it is something that pops up quickly
>>>> right after a
>>>> release". I don't see a reason for binding it to time, and instead we
>>>> could say that we will have a branch release if:
>>>> 1- there is an important bug fix that needs to be released
>>>> 2- we are not close to a trunk release
>>> One problem with our current model is that we create a release placeholder
>>> before we have a release manager for the release. What you are suggesting
>>> makes sense to me, but it introduces another problem.
>>> Today we create release placeholders as soon as we push out a release, we
>>> always have placeholders for the upcoming fix/trunk based releases. This
>>> gives us a place to hang JIRA issues off of, it allows us to triage new
>>> issues and slate them for a particular release.
>>> We could instead go to the model of having only trunk, no placeholder at
>>> all for the fix and next major/minor release (3.3.3/3.4.0 today). Then, at
>>> some point, a release manager could step up and volunteer to do a release,
>>> say 3.3.3, they would then be responsible for determining what's in the
>>> release. They would work with the community to do this, in the end they (the
>>> RM) are the arbiter for what's in/out of the release.
>>> We could try this and see how it works. It would allow for what Ben is
>>> suggesting.
>>> EOD though it requires someone to step up and take on
>>> the responsibility of being the RM. (hint hint :-) )
>>> Patrick
>>>> -Flavio
>>>> On Jan 26, 2011, at 7:27 PM, Benjamin Reed wrote:
>>>> i would really like to get 3.3.3 out because of the fixes that just went
>>>> in.
>>>> there are quite a few bugs that are marked for 3.3.3, but i think they
>>>> can all be pushed to 3.4.0.
>>>> i would really like to push everything to 3.4.0 and then work on getting
>>>> the 3.4.0 release out. we haven't done a release from trunk in a while,
>>>> but that is the only code that gets tested by hadoopqa. i think it is a
>>>> bad idea to be releasing from branches that are not regularly tested.
>>>> going forward doesn't it seem like a better idea to only do a release
>>>> from just a branch if it is something that pops up quickly right after a
>>>> release. otherwise, we should be releasing from trunk and possibly doing
>>>> a simultaneous release from a branch.
>>>> ben
>>>>    *flavio*
>>>> *junqueira*
>>>> research scientist
>>>> fpj@yahoo-inc.com
>>>> direct +34 93-183-8828
>>>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>>>> phone (408) 349 3300    fax (408) 349 3301

View raw message