gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] Performance Translators' Stability and Usefulness


From: Jacques Mattheij
Subject: Re: [Gluster-devel] Performance Translators' Stability and Usefulness
Date: Tue, 07 Jul 2009 12:05:51 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

hello Anand, Geoff & others,

This pretty much parallels my interaction with the team about a
year ago, lots of really good intentions but no actual follow up.

We agreed that an automated test suite was a must and that a
whole bunch of other things would have to be done to get
glusterfs out of the experimental stage and into production
grade.

It's a real pity because I still feel that glusterfs is one of the
major contenders to become *the* cluster file system.

A lot of community goodwill has been lost, I've kept myself
subscribed to this mailing list because I hoped that at some
point we'd move past this endless cat and mouse game with
stability issues but for some reason that never happend.

Anand, you have a very capable team of developers, you have
a once-in-a-lifetime opportunity to make this happen please
take Geoff's comments to hart and get serious about Q&A and
community support because that is the key to any successful
foss project. Fan that fire and you can't go wrong, lose the
community support and your project might as well be dead.

I realize this may come across as harsh but it is intended to
make it painfully obvious that the most staunch supporters
of glusterfs are getting discouraged and that is a loss no
serious project can afford.

 Jacques


Geoff Kassel wrote:
Hi Anand,
If you look back through the list archives, no one other than me replied to the original QA thread where I first posted my patches. Nor to the Savannah patch tracker thread where I also posted my patches. (Interesting how those trackers have been disabled now...)

It took me pressing the issue after discovering yet another bug that we even started talking about my patches. So yes, my patches were effectively ignored.

At the time, you did mention that the code the patches were to be applied against was being reworked, in addition to your comments about my code comments.

I explained the comments as being necessary to avoid the automated tool flagging potential issues again on reuse of that tool - other comments for future QA work. There was no follow up on that from you, nor suggestion on how I might improve these comments to your standards.

I continued to supply patches in the Savannah tracker against the latest stable 1.3 branch - which included some refactoring for your reworked code, IIRC - for some time after that discussion. All of my patches were in sync with the code from publically available 1.3 branch repository within days of a new TLA patchset.

   None of these were adopted either.

I simply ran out of spare time to maintain this patchset, and I got tired of pressing an issue (QA) that you and the dev team clearly weren't interested in.

I don't have the kind of spare time needed to do the sort of in-depth re-audit your code from scratch (as would be needed) in the manner that I did back then. So I can't meet your request at this time, sorry.

As I've suggested elsewhere, now that you apparently have the resources for a stand-alone QA team - this team might want to at least use the tools I've used to generate these patches - RATS and FlawFinder.

That way you can generate the kind of QA work I was producing with the kind of comment style you prefer.

The only way I can conceive of being able to help now is in patching individual issues. However, I can really only feasibly do that with my time constraints if I've got regression tests to make sure I'm not inadvertently breaking other functionality.

   Hence my continued requests for these.

Geoff.

On Tue, 7 Jul 2009, Anand Avati wrote:
  I've also gone one better than just advice - I've given up significant
portions of my limited spare time to audit and patch a not-insignificant
portion of the GlusterFS code, in order to deal with the stability issues
I and others were encountering. My patches were ignored, on the grounds
that it contained otherwise unobtrusive comments which were quite
necessary to the audit.
Geoff, we really appreciate your efforts, both on the fronts of your
patch submissions and for voicing your opinions freely. We also
acknowledge the positive intentions behind this thread. As far as your
patch submissions are concerned, there is probably a misunderstanding.
Your patches were not ignored. We do value your efforts. The patches
which you submitted, even at the time of your submission were not
applicable to the codebase.

Patch 1 (in glusterfsd.c) -- this file was reworked and almost
rewritten from scratch to work as both client and server.

Patch 2 (glusterfs-fuse/src/glusterfs.c) -- this module was
reimplemented as a new translator (since a separate client was no more
needed).

Patch 3 (protocol.c) -- with the introduction of non blocking IO and
binary protocol, nothing of this file remained.

What I am hoping to convey is that, the reason your patches did not
make it to the repository was because it needed significant reworking
to even apply. I did indeed comment about code comments of the style
/* FlawFinder: */ but then, that definitely was _not_ the reason they
weren't included. Please understand that nothing was ignored
intentionally.

This being said, I can totally understand the efforts which you have
been putting to maintain patchsets by yourself and keeping them up to
date with the repository. I request you to resubmit them (with git
format-patch) against the HEAD of the repository.

Thanks,
Avati




_______________________________________________
Gluster-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gluster-devel


--

Jacques Mattheij
+31 6 30 366 241





reply via email to

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