>>> On 7/7/2008 at 2:37 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > 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. >
OK, let's go back and rehash. There were two proposals, 1) Removing the "/C++" portion of the language label "C/C++". The technical reason for rejecting this is basically that it doesn't solve anything yet adds more confusion to the configuration of a module in the next release. The exact same code path would be followed by gmond for either a C or a C++ module, therefore combining both languages into a single language label makes things less confusing for the user. Especially since it would be very difficult for a user to distinguish between a compiled C DSO and a C++ DSO. Both C and C++ would both produce a DSO module that would need to be loaded by apr_dso_load(). Both types of module would interface with gmond in exactly the same way. However if we apply this patch for 3.1.1, it would then require a code change for 3.1.2 when the second patch is applied. 2) Make all of the changes to the source code both in gmond, module headers and modules to support the C++ compi ler. The technical reason for not accepting this patch has already been discussed on this thread. >> 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. > Correct. This can easily be noted in the README as a known issue that will be fixed in 3.1.2 when the C++ backport proposal (#2) is accepted in the 3.1 branch. In the meantime (which is a very short time), C++ is not supported for developing a gmond module. When the C++ backport proposal is accepted into 3.1.2 and 3.1.2 is released, the language label "C/C++" will be fully supported and make complete sense to the user as well as the developer. >> 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. > Ok, but the user doesn't care. Basically to the user, the language that was used to produce the DSO doesn't matter. To gmond, the language that was used to produce the DSO doesn't matter. So all we really need to do is give it a label. The easiest label to give it that will be understood by both users and developers is "C/C++". This label also makes sense when you are talking in terms of alternate languages when referring to Python, perl, ruby, etc. modules. > 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. > Absolutely, however the last patch is too destabilizing for 3.1.1. So rather than applying a label change to 3.1.1 which would have to be reversed for 3.1.2, let's just document that the label is slightly misleading for now. Then let's add the C++ support to 3.1.2 the right way. Again, just because the C++ support is a known issue, doesn't mean we have to fix it now. Especially since there is no demand for a C++ interface which means that it can easily wait. Is the "C/C++" label a little misleading? Sure, but who really cares and what difference does it make for the 3.1.1 release. Document it and move on. >> 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. > Actually I believe that we aren't just close, we are there. With the exception of a potential segfault issue that was identified and proposed for backport, the Ganglia code is ready to go. Even the remaining backport proposal issues can wait if needed. None of them (with the exception of the segfault issue), is a show stopper. The Ganglia code would work well with or without the remaining backports. If the remaining backports make it in, then great. If they don't, the 3.1.1 release is still good. Again the goal is really to stabilize Ganglia 3.1.1 so that we can ship it. Not necessarily to fix every remaining issue no matter how small. So again I am proposing that we backport the potential segfault issue which is described in the STATUS file, roll RC1 (or whatever anybody wants to call it) and start a two week testing cycle towards an official release. Just to be clear, the two weeks is not a hard deadline. What it means is that if there are no showstopper issues found within the two weeks, then we release the candidate. If a showstopper issue is found and resolved, then roll the next RC and the two week time window restarts. Brad ------------------------------------------------------------------------- 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
