<div dir="ltr">On Sun, Jul 28, 2013 at 11:32 PM, Bryan Whitehead <span dir="ltr">&lt;<a href="mailto:driver@megahappy.net" target="_blank">driver@megahappy.net</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Weekend activities kept me away from watching this thread, wanted to<br>

add in more of my 2 cents... :)<br>
<br>
Major releases would be great to happen more often - but keeping<br>
current releases &quot;more current&quot; is really what I was talking about.<br>
Example, 3.3.0 was a pretty solid release but some annoying bugs got<br>
fixed and it felt like 3.3.1 was reasonably quick to come. But that<br>
release seemed to be a step back for rdma (forgive me if I was wrong -<br>
but I think it wasn&#39;t even possible to fuse/mount over rdma with 3.3.1<br>
while 3.3.0 worked). But 3.3.2 release took a pretty long time to come<br>
and fix that regression. I think I also recall seeing a bunch of nfs<br>
fixes coming and regressing (but since I don&#39;t use gluster/nfs I don&#39;t<br>
follow closely).<br></blockquote><div><br></div><div>Bryan - yes, point well taken. I believe a dedicated release maintainer role will help in this case. I would like to hear other suggestions or thoughts on how you/others think this can be implemented.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What I&#39;d like to see:<br>
In the -devel maillinglist right now I see someone is showing brick<br>
add / brick replace in 3.4.0 is causing a segfault in apps using<br>
libgfapi (in this case qemu/libvirt) to get at gluster volumes. It<br>
looks like some patches were provided to fix the issue. Assuming those<br>
patches work I think a 3.4.1 release might be worth being pushed out.<br>
Basic stuff like that on something that a lot of people are going to<br>
care about (qemu/libvirt integration - or plain libgfapi). So if there<br>
was a scheduled release for say - every 1-3 months - then I think that<br>
might be worth doing. Ref:<br>
<a href="http://lists.gnu.org/archive/html/gluster-devel/2013-07/msg00089.html" target="_blank">http://lists.gnu.org/archive/html/gluster-devel/2013-07/msg00089.html</a><br></blockquote><div><br></div><div>Right, thanks for highlighting. These fixes will be back ported. I have already submitted the backport of one of them for review at <span style="color:rgb(0,0,0)"><a href="http://review.gluster.org/5427">http://review.gluster.org/5427</a>. The other will be backported once reviewed and accepted in master.</span></div>
<div><br></div><div>Thanks again!</div><div>Avati</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The front page of <a href="http://gluster.org" target="_blank">gluster.org</a> says 3.4.0 has &quot;Virtual Machine Image<br>
Storage improvements&quot;. If 1-3 months from now more traction with<br>
CloudStack/OpenStack or just straight up libvirtd/qemu with gluster<br>
gets going. I&#39;d much rather tell someone &quot;make sure to use 3.4.1&quot; than<br>
&quot;be careful when doing an add-brick - all your VM&#39;s will segfault&quot;.<br>
<div><div><br>
On Sun, Jul 28, 2013 at 5:10 PM, Emmanuel Dreyfus &lt;<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>&gt; wrote:<br>
&gt; Harshavardhana &lt;<a href="mailto:harsha@harshavardhana.net" target="_blank">harsha@harshavardhana.net</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; What is good for GlusterFS as a whole is highly debatable - since there<br>
&gt;&gt; are no module owners/subsystem maintainers as of yet at-least on paper.<br>
&gt;<br>
&gt; Just my two cents on that: you need to make clear if a module maintainer<br>
&gt; is a dictator or a steward for the module: does he has the last word on<br>
&gt; anything touching his module, or is there some higher instance to settle<br>
&gt; discussions that do not reach consensus?<br>
&gt;<br>
&gt; IMO the first approach creates two problems:<br>
&gt;<br>
&gt; - having just one responsible person for a module is a huge bet that<br>
&gt; this person will have good judgments. Be careful to let a maintainer<br>
&gt; position open instead of assigning it to the wrong person.<br>
&gt;<br>
&gt; - having many different dictators each ruling over a module can create<br>
&gt; difficult situations when a proposed change impacts many modules.<br>
&gt;<br>
&gt; --<br>
&gt; Emmanuel Dreyfus<br>
&gt; <a href="http://hcpnet.free.fr/pubz" target="_blank">http://hcpnet.free.fr/pubz</a><br>
&gt; <a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a><br>
</div></div></blockquote></div><br></div></div>