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

[Brian Foster]

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.

Brian

> Anybody have thoughts or a different view on this? Should we split the
> above responsibility into two roles? Expand the scope?
> 
> Feedback welcome!
> Ava
>  
> 
> 
>     For example, I think the ext4 patches had long been available but they
>     just took forever to get pushed out into an official release.
> 
>     I'm in favor of closing some bugs and risking introducing new bugs for
>     the sake of releases happening often.
> 
> 
>     On Fri, Jul 26, 2013 at 10:26 AM, Anand Avati <address@hidden
>     <mailto:address@hidden>> wrote:
>     > Hello everyone,
>     >
>     >   We are in the process of formalizing the governance model of the
>     GlusterFS
>     > project. Historically, the governance of the project has been loosely
>     > structured. This is an invitation to all of you to participate in this
>     > discussion and provide your feedback and suggestions on how we
>     should evolve
>     > a formal model. Feedback from this thread will be considered to
>     the extent
>     > possible in formulating the draft (which will be sent out for
>     review as
>     > well).
>     >
>     >   Here are some specific topics to seed the discussion:
>     >
>     > - Core team formation
>     >   - what are the qualifications for membership (e.g contributions
>     of code,
>     > doc, packaging, support on irc/lists, how to quantify?)
>     >   - what are the responsibilities of the group (e.g direction of the
>     > project, project roadmap, infrastructure, membership)
>     >
>     > - Roadmap
>     >   - process of proposing features
>     >   - process of selection of features for release
>     >
>     > - Release management
>     >   - timelines and frequency
>     >   - release themes
>     >   - life cycle and support for releases
>     >   - project management and tracking
>     >
>     > - Project maintainers
>     >   - qualification for membership
>     >   - process and evaluation
>     >
>     > There are a lot more topics which need to be discussed, I just
>     named some to
>     > get started. I am sure our community has members who belong and
>     participate
>     > (or at least are familiar with) other open source project
>     communities. Your
>     > feedback will be valuable.
>     >
>     > Looking forward to hearing from you!
>     >
>     > Avati
>     >
>     >
>     > _______________________________________________
>     > Gluster-users mailing list
>     > address@hidden <mailto:address@hidden>
>     > http://supercolony.gluster.org/mailman/listinfo/gluster-users
> 
> 
> 
> 
> _______________________________________________
> Gluster-users mailing list
> address@hidden
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>