<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 28, 2013 at 6:48 AM, Brian Foster <span dir="ltr"><<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/27/2013 02:32 AM, Anand Avati wrote:<br>
><br>
><br>
><br>
> On Fri, Jul 26, 2013 at 5:16 PM, Bryan Whitehead <<a href="mailto:driver@megahappy.net">driver@megahappy.net</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:driver@megahappy.net">driver@megahappy.net</a>>> wrote:<br>
><br>
> I would really like to see releases happen regularly and more<br>
> aggressively. So maybe this plan needs a community QA guy or the<br>
> release manager needs to take up that responsibility to say "this code<br>
> is good for including in the next version". (Maybe this falls under<br>
> process and evaluation?)<br>
><br>
><br>
> Good point. The Gluster community today does not have a dedicated<br>
> release manager. It has been a distributed responsibility of<br>
> prioritizing, tracking, backporting bugs/patches and the responsibility<br>
> keeps taking rounds for releases. I personally think there is value in<br>
> having a dedicated role/person who is responsible for and manages<br>
> release branches.<br>
><br>
> - Be responsible for maintaining release branch.<br>
> - Deciding branch points in master for release branches.<br>
> - Actively scan commits happening in master and cherry-pick those which<br>
> improve stability of a release branch.<br>
> - Handling commits in the release branch.<br>
> - Deciding what outstanding bugs must be fixed for a release.<br>
> - Backporting (with the help of the original author for patches which<br>
> require rebase/conflict resolution) patches to release branches.<br>
> - Deciding on stability of a point in the release branch and making the<br>
> release off it.<br>
><br>
> To give an analogy, think the role of Greg in Linux. It turns out to be<br>
> a very important role, for which we do not have a dedicated person<br>
> today. Today's model of shared responsibility for the above task results<br>
> in leakage (like ext4, and few more in fact). We should surely formalize<br>
> this role and identify the right dedicated person in this process.<br>
><br>
<br>
</div></div>Interesting point indeed, but what about even the role of Linus? I think<br>
Bryan's original point was for more regular major releases (?) even<br>
before thinking about stable release branches and whatnot.<br>
<br>
Another thing that I think is quite interesting, coming from the Linux<br>
perspective, is that on such a huge and federated project the release<br>
isn't necessarily driven by the schedule of the content. Linus basically<br>
decides when he has enough to cut a release (or close the merge window)<br>
and a feature either makes it or waits for the next train to leave the<br>
station. So in other words, there might be just as much value to the<br>
community to cut a release that contains a bunch of significant bug<br>
fixes and no new features as the other way around.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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!</div>
<div><br></div><div>Avati</div><div><br></div></div></div></div>