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
