There was some last minute discussion last week about posting a Ganglia-web tarball alongside the full 3.3.5 release tarball
There is no major technical challenge involved in doing that, but I have some comments about it: - someone (maybe me) should have produced it much earlier in the release cycle for testing: I wouldn't be comfortable producing it at the last minute and instantly making it official. Even though the contents of the tarball would be identical to the contents of the web directory in the full tarball, we still need to maintain a policy of testing every tarball for some number of days. There is always human error even in the simplest of tasks, and the `cooling off' period catches such things. - several times, I've raised the possibility that ganglia-web should diverge again - but without bringing back the old web interface. Future monitor-core releases would have no included web/ component. I think the web team are doing great work, certainly a lot more than I've ever contributed. That is why I was so keen to see their work merge into the main release and become the official web interface. Now I can see that may not be the perfect scenario either, so I think that the best way to let the web releases live up to their full potential is to start making releases at a version number higher than where we are now, e.g. the earlier releases were versioned gweb2-2.20, but now they would just release something like this: ganglia-web-3.4.0.tar.gz ganglia-web-3.4.1.tar.gz (bug fix) ganglia-web-3.5.0.tar.gz (new features) In fact, there could be a minor release every 1-2 months if the development pace continues at the rate it has been going, so we could see 3.8.0 or 3.10.0 by Christmas and that would be perfectly fine. There is no reason not to reach for 3.50.0 or beyond, and there is no expectation that monitor-core must keep up or catch up. The only expectation that I do have is that the releases should not cause confusion, so they should not go back to version numbers < 3.4. It must be unambiguous that there is now only one web/ Based on my experience with the 3.3.5 release, I think that is the best approach for web: a) it is good for packaging, because someone who has ganglia-web 3.3.5 on Debian or Fedora can update to 3.4.0 or 3.5.0 automatically b) it avoids confusion: users always look for the highest release number, they don't have to choose between default web and web2 c) it allows a different release process (e.g. autotools is not needed for releasing PHP code, as there is nothing to compile) There are two issues I can see, these are not major obstacles, just things to be aware of: - released Linux distributions typically accept bug fix revisions (e.g. if they are carrying 3.3.5, they'll accept 3.3.6 with a bug fix or security fix, but they won't accept 3.4.0) - so if ganglia-web 3.5 becomes part of Debian 7.0, then it could be in that catalog for a good 18 months, and the web team may need to keep a branch for backporting the most essential bug fixes to 3.4 - as web will no longer be tied to monitor-core, web should pay close attention to the gmetad version, gmond versions (if the version metric is present), etc and refuse to run with a version that is too old, if we ever reach that scenario. For example, if gmetad 3.5 has some new XML attributes, and if web 3.10 absolutely depends on those attributes, then it will need to check the version. If web and monitor-core are together, then maybe we could be more casual about that and just tell people to use everything from the same tarball. Does anyone have any other alternative to put on the table, or do we just start going down this path, maybe with a web-3.4 release this month? ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
