<div dir="ltr">On Mon, Jul 29, 2013 at 2:17 PM, Joe Julian <span dir="ltr"><<a href="mailto:joe@julianfamily.org" target="_blank">joe@julianfamily.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As one of the guys supporting this software, I agree that I would like bugfix releases to happen more. Critical and security bugs should trigger an immediate test release. Other bug fixes should go out on a reasonable schedule (monthly?). The relatively new CI testing should make this a lot more feasible.<br>
</blockquote><div><br></div><div>Joe, we will certainly be increasing the frequency of releases to push out bug fixes sooner. Though this has been a consistent theme in everybody's comments, your feedback in particular weighs in heavily because of your level of involvement in guiding our users :-)</div>
<div><br></div><div>Avati</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If there weren't hundreds of bugs to examine between releases, I would happily participate in the evaluation process.<div class="HOEnZb"><div class="h5"><br>
<br>
On 07/26/2013 05:16 PM, Bryan Whitehead 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 "this code<br>
is good for including in the next version". (Maybe this falls under<br>
process and evaluation?)<br>
<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'm in favor of closing some bugs and risking introducing new bugs for<br>
the sake of releases happening often.<br>
<br>
<br>
<br>
On Fri, Jul 26, 2013 at 10:26 AM, Anand Avati <<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
We are in the process of formalizing the governance model of the GlusterFS<br>
project. Historically, the governance of the project has been loosely<br>
structured. This is an invitation to all of you to participate in this<br>
discussion and provide your feedback and suggestions on how we should evolve<br>
a formal model. Feedback from this thread will be considered to the extent<br>
possible in formulating the draft (which will be sent out for review as<br>
well).<br>
<br>
Here are some specific topics to seed the discussion:<br>
<br>
- Core team formation<br>
- what are the qualifications for membership (e.g contributions of code,<br>
doc, packaging, support on irc/lists, how to quantify?)<br>
- what are the responsibilities of the group (e.g direction of the<br>
project, project roadmap, infrastructure, membership)<br>
<br>
- Roadmap<br>
- process of proposing features<br>
- process of selection of features for release<br>
<br>
- Release management<br>
- timelines and frequency<br>
- release themes<br>
- life cycle and support for releases<br>
- project management and tracking<br>
<br>
- Project maintainers<br>
- qualification for membership<br>
- process and evaluation<br>
<br>
There are a lot more topics which need to be discussed, I just named some to<br>
get started. I am sure our community has members who belong and participate<br>
(or at least are familiar with) other open source project communities. Your<br>
feedback will be valuable.<br>
<br>
Looking forward to hearing from you!<br>
<br>
Avati<br>
<br>
</blockquote></blockquote>
<br>
</div></div></blockquote></div><br></div></div>