On Mon, Jul 07, 2008 at 12:31:13PM -0600, Brad Nicholes wrote: > >>> On 7/4/2008 at 12:58 AM, in message <[EMAIL PROTECTED]>, Carlo > Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 03, 2008 at 10:42:06AM -0700, Bernard Li wrote: > >> -1 > >> > >> I agree with Brad on this. > > > > Not sure what to make of no one replying to the code on this thread, after > > all this is a developer mailing list and I would expect all debate to be > > made in a technical basis. > > The technical reason for not accepting this proposal at this time is the risk > of destabilizing the 3.1 branch before releasing 3.1.1 without solving any > real issue.
This thread code (which has been long removed from the conversation) was mainly documentation changes and code removal in 1 line of code which has no chance of destabilizing anything. I agree with you that the alternative (which is all we had left after this one has been rejected) has a risk of destabilizing the 3.1 branch, and that is why it was delayed for next release originally with an intermediate solution posted in the interim. > The goal right now is to stabilize the 3.1 branch so that we can release > 3.1.1. Adding support for a C++ compiler is closer to being an enhancement > similar to adding support for perl or ruby, than it is a bug fix. Agree, just wanted to clarify though that the added support is not for a compiler but for a language. In the line of compiler support, Sun Studio 12 support was added by me to trunk long ago as an alternative to GCC in OpenSolaris but as I agree with you on the need to keep 3.1 stable for release wasn't even proposed to backport yet. As it is now, you can use the "C" gmond modular interface (which was labeled "C/C++") to write "C" modules or "Objective C" modules but "C++" is not supported yet. > For the 3.1.1 release, this is simply a matter of documentation and noting > that the unsupported "C++" portion of the language label "C/C++" is a known > issue that will be resolved in the next release. There are 2 parts of it which seem to be confusing most : 1) the documentation and use of "C/C++" as a label for DSO modules is incorrect because technically speaking the interface exported by gm_metric.h is a "C" interface which can be used to build DSO modules in almost anything that can compile to it, including using it directly by "C", "Objective C" or "C++" (once the support is committed) source modules and because those other languages are mostly "C" compatible at the source level. 2) the documentation and use of "C/C++" is misleading because "C++" can't be used with it yet (until support is committed). the solution you propose only mitigates 2; the last patch I proposed mitigates both. > Let's do what is necessary to get 3.1.1 out the door And I think we are getting closer, with the help of package maintainers and more people testing/using snapshots, at least to get a well supported beta out very soon, once all those last minute bugfixes that are still being worked out are backported or dropped. Carlo ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
