[Gluster-devel] [Gluster-users] [FEEDBACK] Governance of GlusterFS project

[Vijay Bellur]

On 07/29/2013 12:02 PM, Bryan Whitehead wrote:
> 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).

Establishing a release criterion for minor releases could help here. It 
need not be very fancy and as lightweight as:

- all regression tests in glusterfs.git should pass

If we ship a minor release with a regression, it would then be a matter 
of fixing our regression test suite.

Right now, the regression test suite cannot handle indicative deployment 
scenarios as all tests run on a single node. However, if there are QE 
volunteers in the community, we can ensure that a set of functional 
tests pass on various configurations prior to a minor release.

>
> 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".
>


I think this is a very valid point. Having an established cadence for 
minor releases, say every 6 weeks, could be one model that will help 
fixes go out sooner. We can also decide on what is absolutely necessary 
for a minor release through an IRC meeting (we need a cadence for IRC 
meetings too - that is a separate activity to be accomplished). Both for 
major and minor releases, moving to a date driven approach from a 
content driven mechanism should work better. Dates can be pushed only if 
there are significant blockers.

Fixes for security and extremely critical problems can happen 
asynchronously without having to wait for the scheduled date to be met.

-Vijay