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 >>> >>> >>> >> >
