[Gluster-users] [Gluster-devel] [FEEDBACK] Governance of GlusterFS project
driver at megahappy.net
Mon Jul 29 06:32:15 UTC 2013
Weekend activities kept me away from watching this thread, wanted to
add in more of my 2 cents... :)
Major releases would be great to happen more often - but keeping
current releases "more current" is really what I was talking about.
Example, 3.3.0 was a pretty solid release but some annoying bugs got
fixed and it felt like 3.3.1 was reasonably quick to come. But that
release seemed to be a step back for rdma (forgive me if I was wrong -
but I think it wasn't even possible to fuse/mount over rdma with 3.3.1
while 3.3.0 worked). But 3.3.2 release took a pretty long time to come
and fix that regression. I think I also recall seeing a bunch of nfs
fixes coming and regressing (but since I don't use gluster/nfs I don't
What I'd like to see:
In the -devel maillinglist right now I see someone is showing brick
add / brick replace in 3.4.0 is causing a segfault in apps using
libgfapi (in this case qemu/libvirt) to get at gluster volumes. It
looks like some patches were provided to fix the issue. Assuming those
patches work I think a 3.4.1 release might be worth being pushed out.
Basic stuff like that on something that a lot of people are going to
care about (qemu/libvirt integration - or plain libgfapi). So if there
was a scheduled release for say - every 1-3 months - then I think that
might be worth doing. Ref:
The front page of gluster.org says 3.4.0 has "Virtual Machine Image
Storage improvements". If 1-3 months from now more traction with
CloudStack/OpenStack or just straight up libvirtd/qemu with gluster
gets going. I'd much rather tell someone "make sure to use 3.4.1" than
"be careful when doing an add-brick - all your VM's will segfault".
On Sun, Jul 28, 2013 at 5:10 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:
> Harshavardhana <harsha at harshavardhana.net> wrote:
>> What is good for GlusterFS as a whole is highly debatable - since there
>> are no module owners/subsystem maintainers as of yet at-least on paper.
> Just my two cents on that: you need to make clear if a module maintainer
> is a dictator or a steward for the module: does he has the last word on
> anything touching his module, or is there some higher instance to settle
> discussions that do not reach consensus?
> IMO the first approach creates two problems:
> - having just one responsible person for a module is a huge bet that
> this person will have good judgments. Be careful to let a maintainer
> position open instead of assigning it to the wrong person.
> - having many different dictators each ruling over a module can create
> difficult situations when a proposed change impacts many modules.
> Emmanuel Dreyfus
> manu at netbsd.org
More information about the Gluster-users