>>> On 10/30/2007 at 9:55 AM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Hi Brad: > > On 10/30/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: > >> > Going forward (3.1.x) -- how should this be fixed? >> > >> > P.S. I currently have no plans to accept any patches into the 3.0.x >> > branch (unless of course if the community wants it) -- all new stuff >> > should go into trunk (i.e. 3.1.x). >> > >> > Cheers, >> > >> > Bernard >> > >> >> It depends. There is nothing preventing the release of a 3.0.6, .0.7, .0.8, > etc. as long as there is somebody willing to make the release and there are > bug fixes that warrant it. I don't know if this bug warrants a new release > or not so we would probably have to get more feedback from the community. It > also depends on how long it will be before we release our first version of > 3.1.x. If it is just a month or two away, then I would probably vote against > releasing a new 3.0.x version. However if the first 3.1.x release is a year > down the road, then a 3.0.x release might be a good idea. >> >> Going back to how the Apache httpd project works, the project itself doesn't > really care if an older revision is released. As long as there is somebody > willing to put the work in to make the release. Even though the current > version of the web server is 2.2.x, they are still making releases of 1.3.x > and 2.0.x. Having said that, the project is very much against adding any new > features to an older version of the web server. An older version is only > re-released when there is a bug fix that the project feels warrants back > porting and releasing. The next major factor is that there is somebody in > the community that is willing to put in the effort to actually create the > release. This is where the rest of the Ganglia community should step up. > Open Source software is all about "scratching your own itch". I wouldn't > expect Bernard to have to be the one that always puts in the hours to create > a new release ( of course unless he wants to). Especially if the bugs being > fixed by the release are not important to him (or his employer). Those that > want this bug fixed in a 3.0.x version, could be the ones who create the new > release. So if getting *this* bug fixed in a 3.0.x release is important to > the community, then lets hear about it on the mailing list. If not, then > lets just wait for a 3.1.x release. > > Perhaps I wasn't clear regarding what my question was. Basically you > suggested that for 3.1.x we simply write a python module to get around > the 4T limit, whereas what I was really asking is should we dig into > the core and fix it there. >
I haven't looked at the 4T issue close enough to know whether it is just a metric problem or a core gmond problem (or both). When I say 'core', I am referring to gmond itself which does not include metric.c. I consider metric.c to be outside of gmond core. So if there isn't an issue passing a huge number through gmond core (ie. the internal variables can handle a huge number) then I do believe that the issue can be handled by implementing either a C or python module that can handle 4T. Otherwise, we will have to make changes to gmond 3.1.x core as well. At the very least, a 4T number can be represented by a smaller factor which would allow a suitable solution to be fully implemented in a module. Of course if the community wants a 3.0.x solution, that would be a completely different patch. > However, you brought up interesting points, and I think it reflects my > sentiments. Given the limited number of Ganglia developers right now, > and having to move the project forward, I think it is prudent to focus > our developer efforts on the 3.1.x release. > > And if the community wants another 3.0.x release and someone is > willing to step up and do it, why not? > > On the same token, perhaps we should try to arrange for a developer's > meet up to talk about all the great ideas that we have accumulated in > the '3.1.0 wishlist' thread. During that time we can figure out when > we can release 3.1.0 -- I am hoping sooner (months), rather than later > (year). > > I hope to wrap up the spec file update soon -- those of you (package > managers, please) who have not voiced their opinions, please do so > soon. > Total agreement. I think that we have a long list of enhancements for several 3.1.x releases. I don't believe that they all have to be done before we release 3.1.0. Obviously we will need to identify any enhancements that will break compatibility and make sure that those are included in 3.1.0. Then moving forward, other new features can come when they come. I would like to see the development community (and anybody else interested) get together soon either virtually or physically to discuss the wish list and determine what *must* be done for a 3.1.0 release. I am very interested in seeing a 3.1.0 release in the very near future. When can we make this happen? Brad ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
