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. 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 <anand.avati at gmail.com > <mailto:anand.avati at gmail.com>> 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 > > Gluster-users at gluster.org <mailto:Gluster-users at gluster.org> > > http://supercolony.gluster.org/mailman/listinfo/gluster-users > > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >
