On Sun, Jul 28, 2013 at 6:48 AM, Brian Foster <bfoster at redhat.com> wrote: > On 07/27/2013 02:32 AM, Anand Avati wrote: > > > > > > > > On Fri, Jul 26, 2013 at 5:16 PM, Bryan Whitehead <driver at megahappy.net > > <mailto:driver at megahappy.net>> wrote: > > > > I would really like to see releases happen regularly and more > > aggressively. So maybe this plan needs a community QA guy or the > > release manager needs to take up that responsibility to say "this > code > > is good for including in the next version". (Maybe this falls under > > process and evaluation?) > > > > > > Good point. The Gluster community today does not have a dedicated > > release manager. It has been a distributed responsibility of > > prioritizing, tracking, backporting bugs/patches and the responsibility > > keeps taking rounds for releases. I personally think there is value in > > having a dedicated role/person who is responsible for and manages > > release branches. > > > > - Be responsible for maintaining release branch. > > - Deciding branch points in master for release branches. > > - Actively scan commits happening in master and cherry-pick those which > > improve stability of a release branch. > > - Handling commits in the release branch. > > - Deciding what outstanding bugs must be fixed for a release. > > - Backporting (with the help of the original author for patches which > > require rebase/conflict resolution) patches to release branches. > > - Deciding on stability of a point in the release branch and making the > > release off it. > > > > To give an analogy, think the role of Greg in Linux. It turns out to be > > a very important role, for which we do not have a dedicated person > > today. Today's model of shared responsibility for the above task results > > in leakage (like ext4, and few more in fact). We should surely formalize > > this role and identify the right dedicated person in this process. > > > > Interesting point indeed, but what about even the role of Linus? I think > Bryan's original point was for more regular major releases (?) even > before thinking about stable release branches and whatnot. > > Another thing that I think is quite interesting, coming from the Linux > perspective, is that on such a huge and federated project the release > isn't necessarily driven by the schedule of the content. Linus basically > decides when he has enough to cut a release (or close the merge window) > and a feature either makes it or waits for the next train to leave the > station. So in other words, there might be just as much value to the > community to cut a release that contains a bunch of significant bug > fixes and no new features as the other way around. Right, and this _hasn't_ been the model we have been following. Linux's model has been release-early/release-often - which certainly has benefits, while Gluster's model has been more waterfall'ish - commit a set of big features up front, and work on delivering it by the release date and pick up any bug fixes along the way which have made it by then -- possibly delaying the release if there are delays in feature development, effectively also delaying bug fixes to go out. In case of the Ext4 d_off bug, it was slippage on our part for not backporting it into the 3.3 branch and making a minor release off it, but that may not always be the case - when a bug is fixed by an architectural change which is too invasive for a backport. The question really is for our users (more than developers) - are features and feature delivery of more interest, or a release-early/release-often model? Bryan's comment seems to suggest the latter. I'm sure there are others here with an opinion on this! Avati -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130728/e15304b2/attachment-0001.html>
