<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 5:16 PM, Bryan Whitehead <span dir="ltr">&lt;<a href="mailto:driver@megahappy.net" target="_blank">driver@megahappy.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 &quot;this code<br>
is good for including in the next version&quot;. (Maybe this falls under<br>
process and evaluation?)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>- Be responsible for maintaining release branch.</div><div>- Deciding branch points in master for release branches.</div><div>- Actively scan commits happening in master and cherry-pick those which improve stability of a release branch.</div>
<div>- Handling commits in the release branch.</div><div>- Deciding what outstanding bugs must be fixed for a release.</div><div>- Backporting (with the help of the original author for patches which require rebase/conflict resolution) patches to release branches.</div>
<div>- Deciding on stability of a point in the release branch and making the release off it.</div><div><br></div><div>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&#39;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.</div>
<div><br></div><div>Anybody have thoughts or a different view on this? Should we split the above responsibility into two roles? Expand the scope?</div><div><br></div><div>Feedback welcome!</div><div>Ava</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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