On Mon, Jul 07, 2008 at 05:03:59PM -0600, Brad Nicholes wrote: > > 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.
This was r1490 and proposed in : http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg04389.html Was made of a simple documentation update removing the "C++" references in the code and changing the optional "language" directive to use "c" instead. I wasn't planning on adding the "C++" part back in the next release and no patch was ever shown doing so, that was only presented as an option because you were arguing that was the correct thing to do once "C++" support was added, even if you also contradicted yourself but then arguing that the "language" directive for DSO is not really meant to be interpreted literally to indicate which language was used once pointed out that you can now use "Objective C" and will be able to use any other language to build DSO in the future, as far as they can use the "C" interface exported by gm_metric.h either directly (like "C++" will do and "Objective C" does now) or indirectly. > 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. No if we just use (and document) this as a "C" interface instead dealing that way with any ambiguity and simplifying the code so that there are also no changes required in the future as more languages are used to generate compiled DSOs (as they are all irrelevant anyway since they all use the same interface) > 2) Make all of the changes to the source code both in gmond, module headers > and modules to support the C++ compiler. Not really, the second option corresponds to r1500 and was presented here : http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg04408.html Which just updates the documentation to remove any ambiguity and also the "language" directive for DSO (as it was meaningless anyway and no label is as good as an arbitrary meaningless one) Adding the "language" directive back for consistency as you argued (even if it goes against the code simplicity you mentioned originally) is OK, if it lets us get out of the current deadlock. Committed revision 1530 > The technical reason for not accepting this patch has already been discussed > on this thread. This is the third option, which I think we all agree is too risky, but that is all that is left if every attempt I made has been rejected with no counter proposals in code. It also has the disadvantage that it doesn't remove any ambiguities in the documentation leaving us open for a future "Objective C" developer asking for a code change just because his favorite language is not identified by the current one. > > 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. except for the "Objective C" developer which will be building modules in 3.1.1 and wondering why "C++" is mentioned there if not supported while "ObjC" is not, even if it is working. > > 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. > > 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++". why it is not "C"? (as on "C" interface or "C" bindings) > > 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. This is directed to the wrong patch as explained above. Hopefully a new third proposal (based in r1530) could be used instead allowing us to continue without having to risk stability for the first release of 3.1 > >> 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. To be "there" we need to either commit or defer all known issues, otherwise releasing a package for testing won't be effective, and as of last Thursday there were patches being recently proposed for backport which were aimed (fairly or not) for this release as you can see by the following snippet : svn diff -c1503 STATUS Index: STATUS =================================================================== --- STATUS (revision 1502) +++ STATUS (revision 1503) @@ -128,3 +128,4 @@ http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=186 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1480 +1: bernardli + bernardli: Why can't this patch be backported in the current version? > With the exception of a potential segfault issue that was identified and > proposed for backport, the Ganglia code is ready to go. ignoring the `gmond -m` failures with python modules, or the fact that fedora linux ppc64 won't build unless a patch is added (which can't be committed upstream or will break AIX like it did break amd64 BSD) > 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. 2 weeks might be a little optimistic, specially considering how long it takes to decide something as simple as the language label to use for DSO compiled modules, but also by the fact that getting ganglia setup in a small cluster and exercised enough (including building some modules) will take more than that, resulting in potentially show stopper issues found after the release (like the segfault you refer to, and that took Daniel, who is an exceptionally dedicated tester, more than 1 week to find). Getting packages to use for testing with a stable beta would help easy the process and hopefully get us more coverage, but I would argue that our testing cycles are closer to 4 weeks than to 2, and we won't be able to get any testers unless we seriously freeze the bugfix/features stream and are fully dedicated getting all reported issues fixed). 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
