[Gluster-devel] [Gluster-users] [FEEDBACK] Governance of GlusterFS project

[Anand Avati]

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-devel/attachments/20130728/e15304b2/attachment-0001.html>