Re: Performance Translators' Stability and Usefulness

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

 



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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux