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

[Anand Avati]

On Sun, Jul 28, 2013 at 6:48 AM, Brian Foster <address@hidden> wrote:

On 07/27/2013 02:32 AM, Anand Avati wrote:
>
>
>
> On Fri, Jul 26, 2013 at 5:16 PM, Bryan Whitehead <address@hidden

> <mailto:address@hidden>> 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