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.

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.

Thanks!

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

Reply via email to