>>> On 10/29/2007 at 4:43 PM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Hi Chris, Brad: > > (Forwarding to ganglia-developers) > > 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 th e 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. Brad > On 10/29/07, Chris Slaughter <[EMAIL PROTECTED]> wrote: >> Sorry for the delay. I finally had time to put them together, using >> the new 3.0.5 (I was running a pre-release 3.0.5 before). This is >> a very ugly hack, but I haven't found a better way to do it in the >> 3.0 series. Here is a brief description of the patches: >> >> For metrics.c, divide the various memory totals by 1024. >> >> For graph.php, 'trick' the graphs into using the 'correct' units, >> since we are now off by 1024. I don't remember why I needed >> to use 1048576 for the graph, but that is what worked. >> >> I'm sure there is a better way to do this, and I welcome any >> comments. >> >> On 9/11/07, Jim Rowan <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Yes -- If you don't mind, please send me your changes. Thanks! >> > >> > >> > Chris Slaughter wrote: >> > >> > >The problem is that memory is currently stored as an uint32, so it > overflows >> > >at a little over 4TB. Since it is hardcoded, 32- vs. 64-bit doesn't make >> > >a >> > >difference. >> > > >> > >I took a look at the code at one point, but it wasn't as simple as >> > >changing >> > >it to a uint64, so I took the route of 'fudging' all of the memory values. >> > >I ended up dividing the values by 1024, and then adding a hack in the >> > >graph >> > >so the values are displayed as T instead of M... >> > > >> > >If you are interested, I can grab my changes on Monday when I am in the >> > >office. >> > > >> > >Chris Slaughter >> > > >> > > >> > >On 9/7/07, Bernard Li <[EMAIL PROTECTED]> wrote: >> > > >> > > >> > >>Hi Jim: >> > >> >> > >>On 9/7/07, Jim Rowan <[EMAIL PROTECTED]> wrote: >> > >> >> > >> >> > >> >> > >>>We have a cluster with more than 4T of memory. Ganglia (3.0.4) won't >> > >>>show that on the graphs, although if you visit the physical view it >> > >>>seems to have the correct number. If you restart all the gmonds, the >> > >>>summary memory graph looks like a sawtooth; ramping up to 4T and >> > >>>dropping suddenly to zero as it wraps around, and ramps up again. >> > >>> >> > >>>Where is the problem likely to be? >> > >>> >> > >>> >> > >>This bug has already been filed: >> > >> >> > >>http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=128 >> > >> >> > >>But no solutions yet... >> > >> >> > >>Cheers, >> > >> >> > >>Bernard >> > >> ------------------------------------------------------------------------- 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
