Shehjar Tikoo wrote:
Finally - which translators are deemed stable (no know issues -
memory leaks/bloat, crashes, corruption, etc.)?
We can definitely vouch for a higher degree of stability of the
releases. Otherwise, I dont think there is any performance translator
we can call completely stable/mature because of the roadmap we have
for constantly upgrading algorithms, functionality,
etc.
When will the Gluster team be able to deliver a stable, mature, and
reliable version of GlusterFS?
Continuing from what I said earlier, the fact that GlusterFS releases
work in a stable manner is shown by the deployments among our
customers.
At the same time, are we satisfied with the experience of non-paying
users?
No. I accept there are bottlenecks in our processes. We
acknowledge that and have been working on fixing them.
I'm glad the issue of paying vs. non-paying customers has been brought
up. I have mentioned to some of the development team that I am not
averse to the idea of becoming a paying customer, but the enthusiasm for
encouraging this just didn't seem to be there. The two things I would
potentially be interested in are:
1) Specific bug-fix sponsorship
2) Feature sponsorship
From what I can tell, however, the developers' operating model isn't
geared up toward that.
When will regression tests be used? It's been months now since this
bug, and still I don't see any sign of the use of this simple,
industry-standard technique to minimise the risk of such issues
slipping through again.
I think the QA folks have done some really good work in stabilizing
GlusterFS over the last year or so. The result is there to see in the
2.0.X releases.
I have to say that up until 2.0.2, which works reasonably well, the path
from late 1.4.x that became 2.0.0qa1 up to and including 2.0.1 has been
more than a little dicey. That's a long time to stabilize a release.
I think there needs to be a split between stable (bug fixes _ONLY_!) and
development releases (new/experimental features, redesign of parts of
the system such as format of xattr metadata, etc.). And the priority
should be given to stable release bug fixes under almost all
circumstances. That way those that want new features can decide for
themselves if the stability trade-off is worth it, and those of us who
are happy with a smaller feature set but require very high stability
don't have to suffer the instability caused by new and experimental
features. What seems to have happened since the 1.3/1.4 split, is that
support of the stable releases has been effectively dropped in favour of
pouring all development effort into 1.4->2.0 releases. This left the
users whose first priority is stability in a position where they cannot
seriously consider using the software in a production environment.
Why wasn't this prioritised after such a disasterous bug?
It could've been for any number of reasons ranging from problems with
reproducing it, limited functionality for managing bug reports in
Savannah to even the general constraints of being a commercial
open-source project.
Still, I understand your problems are more important to you than the
problems being faced by other users, I'd so appreciate if you'd give our
bugzilla-based setup a chance at handling this bug. Or, let me
know if you've already filed a report.
I'm not sure what Geoff's opinion on this is, but I don't think the
issue has been in the bug reporting mechanism. It looks more like
stability just wasn't deemed an important requirement until quite recently.
Gordan
