Hi Vladimir, I'm a little nervous about this for a couple of reasons:
a) the tag doesn't cover the ganglia-web stuff b) the tag is created before testing (which is not necessary when using git, you can tag after you test, because a tag is just a checksum of what you tested) c) package-ganglia-release does things that can be done for us by autotools `make dist' logic - in fact, if `make dist' was used, the problem with the version numbers within configure.in would have been obvious Given that everyone is 100% committed to the new web UI, can I propose that we do a subtree merge to bring monitor-core and web into the same repo? http://progit.org/book/ch6-7.html This will preserve all the history of the web2 branch I just feel that Ganglia already diverges from autotools best practice in a number of ways (e.g. the nested configure for libmetrics, or the way --with-libsomething is used) and that if things can be simplified it will make the process less tedious and more effort can go into testing, etc. Regards, Daniel On 10/03/12 20:14, Vladimir Vuksan wrote: > You will need to tag the monitor-core release then run > > scripts/package-ganglia-release 3.3.2 > > from monitor-core. It will pull in the ganglia-web submodule in the tree. > > Vladimir > > On Sat, 10 Mar 2012, Daniel Pocock wrote: > >> On 09/03/12 16:57, Daniel Pocock wrote: >>> >>> On 09/03/12 15:42, Carlo Marcelo Arenas Belon wrote: >>> >>>> On Thu, Mar 08, 2012 at 04:34:19PM +0100, Daniel Pocock wrote: >>>> >>>>> Michael, do you have write access on the wiki? I think we need to >>>>> get >>>>> this distribution-specific stuff captured there along with the >>>>> general >>>>> notes I provided below. >>>>> >>>> having this instructions added to the codebase just like README.WIN is >>>> could help too, specialy considering there is a fair ammount of >>>> confusion now with information (not all of it consistent with each >>>> other) between the multiple wikis and website. >>>> >>> >>> I will definitely add my notes to either the github wiki or the >>> codebase >>> - but not both. I think the wiki is better because it is easier to >>> format things (e.g. code blocks) >>> >>> >> >> Done: >> >> https://github.com/ganglia/monitor-core/wiki/BuildingARelease >> >> Can someone add in the other steps that have been mentioned for adding >> the web/* stuff to the tarball? >> >> Are there any tests that anyone would like to add for checking a tarball >> before release? >> >> The github wiki is not so friendly with numbering and nested lists, >> notice how the last two items get indented when they should not be? I >> spent more time trying to figure that out than writing the steps, so >> maybe we should use Moin or some other wiki, I've found that much more >> friendly. >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Ganglia-developers mailing list >> Ganglia-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ganglia-developers >> ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
