>>> On 6/23/2008 at 5:43 AM, in message <[EMAIL PROTECTED]>, Stephan Wonczak <[EMAIL PROTECTED]> wrote: > Hi Brad! > (My original mail has not appeared yet on the list - I had a skew > between subscription and sender address. This is now resolved; can a > moderator approve my previous mail?) > > On Thu, 19 Jun 2008, Brad Nicholes wrote: > >> Please see my other post as a response to you concerns. > > *nod* Even so, I still have the feeling this 3.1-release is a bit too > rushed if you have issues like the CentOS4 one remaining. For my part I > would recommend doing like Carlos suggests: Do an 'official' beta release > (with these known difficulties attached) to get a wider audience for > testing (integration into Fedora Core or even Fedora EPEL might be a good > idea). If that does not turn up anything major, make a 'real' relese of > 3.1. If something comes up, you can always do a new beta release. > To keep things in perspective, I am aware that even that process will > not shake out all the bugs, but I think an effort should be made to get a > fresh set of eyes on the code. >
This is actually exactly what I was suggesting except I called it RC1 rather than Beta1. As I mentioned before, I really don't care what we call the tarball, it is the testing and review process that is important. If testing and review produces nothing, then the tarball becomes a release. If however, the testing does produce a showstopper issue, then fix it, re-roll and retest. Eventually you will produce a release tarball. The point is that we start making progress towards a release rather than waiting around for something magical to happen. >>> I fully agree. Even if we (in Cologne) are too pressed for time and warm >>> bodies to do any testing, we would love to upgrade to 3.1. But more or >>> less becoming a beta tester is not something we would do in our production >>> environment. A stable release has to be just that: a stable release. >> >> I will say here that nobody would expect you to use your production >> environment for beta testing or even trying out a new "stable" release >> of any software. However what the Ganglia project lacks is testers. We >> have a lot of Ganglia users that rely on our tried and true 3.0.x >> version of Ganglia but we don't have many who are willing to spend time >> helping us test new features. As I have requested before on this list, >> please join us and help us make Ganglia the best it can be. You don't >> have to develop code to make a difference in the quality of the Ganglia >> software. > > All of the above is true - I would really love to help. But, as I said > before, we are really tight on manpower here, so we do not have enough > resources to actually do anything (much). For example, building a new > snapshot of the source every few days simply is too much time for us. > Quite apart from the fact that we have a policy 'no make; make > install'-software. It *has* to be RPM. > If there was a set of (beta) RPMs that we could simply drop onto a few > of our client nodes we could probably do something. On the other hand, we > are still using Ganglia gmetad 2.5.7 and IIRC 3.1.x will not really work > together with this. Correct? But building a test environment is too much > work for a tool like this, unfortunately. > Whatever you can do to help out is greatly appreciated. I'm not sure that many companies understand that allowing their employees to spend a little time helping an Open Source project produce a better product, is not time wasted. The company benefits because the product quality is better for it and so does the rest of the community. It's all a community effort. Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
