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 follow closely). 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: http://lists.gnu.org/archive/html/gluster-devel/2013-07/msg00089.html 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 > http://hcpnet.free.fr/pubz > manu at netbsd.org
