gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] [Gluster-users] [FEEDBACK] Governance of GlusterFS p


From: Vijay Bellur
Subject: Re: [Gluster-devel] [Gluster-users] [FEEDBACK] Governance of GlusterFS project
Date: Mon, 29 Jul 2013 12:35:49 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]