|Subject:||Re: [Gluster-devel] gluster server 3.0 < crashing on ibverbs under moderate load|
|Date:||Wed, 27 Jan 2010 13:33:21 +0000|
|User-agent:||Thunderbird 126.96.36.199 (X11/20090625)|
Mickey Mazarick wrote:
Just a suggestion, but maybe we can label releases as rc once it has been tested by the dev team but not by the community at large. That way the more conservative deployments can feel better and we know what we're getting into.
I've been saying that for a while. The comprehensiveness of the testing process is somewhat underspecified, especially for a file system. By current versioning, I see rc releases as pre-alpha, and actual releases vary between beta and stable (call it beta if the last bit of the version number is less than about 6).
I'd suggest that the release cycle should be such that when a new version is released with current level of QA, it is first released for at least 1-2 months as "unstable" for highly technical users (e.g. people on the devel as opposed to users list) to test and experiment with and iron out any major issues.
This would slow down the "stable" release cycle and ensure that when something is released as non-beta it is sufficiently stable to not alienate the people who need to use it in production.
Take GFS2 for comparison. It was released as unstable tech preview in RHEL 5.0. The stable release was supposed to be released in RHEL 5.1, but this kept being postponed with new issues being found until 5.4 before it was deemed stable, about 18 months later. That is the sort of stabilization schedule I'd reasonably expect for something as critical as a file system.
That being said I find 2.0.9 to be rock solid in all the situations I've tried.
It's certainly the most stable release available, but it's not perfect. There are segfault issues with it that have been fixed since then should be in the 2.0.10 release when that is out.
|[Prev in Thread]||Current Thread||[Next in Thread]|