On Wed, Jan 26, 2011 at 12:39 PM, Benjamin Reed <br...@yahoo-inc.com> wrote: > 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. >
We wouldn't have to adopt everything, just the bits we like. re 3.4.0 vs 3.4.1, a RM is responsible for a single release. It would be up to that person to sign up for a subsequent release, or not. Someone else would have to pickup the ball in that case. Another good reason for having more committers. > 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. This is what you were referring to in your follow-up email on this thread, right? What you are saying here is what the RM would have to do. Pull patches from trunk to include in the fix release. In some cases though the RM would be on the hook to get the patch backported (or do the work themselves). Hopefully this person would work closely with the community to capture the patches they are interested in, but eod it's up to the RM what they will include. Of course the PMC could then reject the release .... etc... Patrick > > ben > > 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<ph...@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<ph...@apache.org> wrote: >>> >>>> On Wed, Jan 26, 2011 at 10:38 AM, Flavio >>>> Junqueira<f...@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 >>>>> >>>>> f...@yahoo-inc.com >>>>> direct +34 93-183-8828 >>>>> >>>>> avinguda diagonal 177, 8th floor, barcelona, 08018, es >>>>> phone (408) 349 3300 fax (408) 349 3301 >>>>> >>>>> >>>>> > >
