Hi Vladimir,
`inadequate' is not what I am suggesting. Nor am I saying it is broken. Rather, I think it adds extra steps that are possibly avoidable. When I build a ganglia-modules-linux release, everything is done for me by autotools: git checkout autoreconf --install ./configure make dist I just have to make sure that every Makefile.am declares the files that belong in distributions (and occasionally I forget to do that and release something with man page missing, etc). `make dist' reads the metadata and does the work. I actually believe that the main configure.in for Ganglia could be simplified down to little more than what I have in ganglia-modules-linux/configure.ac: http://sourceforge.net/p/gmod-linux/code/ci/2dbf3ee8223e538d6358bc73ebf7912a97796fd0/tree/configure.ac?force=True I'm not sure about whether to overhaul things like this for the 3.3.2 release, but this is a pattern I've repeated for a number of projects now and I really feel it saves me time (and potentially anyone else who wants to make a release). E.g. you can see I do it exactly the same way in dynalogin, and the configure file there is even more basic, in fact, it's as basic as it can possibly be: http://dynalogin.git.sourceforge.net/git/gitweb.cgi?p=dynalogin/dynalogin;a=blob_plain;f=configure.ac;hb=HEAD Regards, Daniel On 10/03/12 21:37, Vladimir Vuksan wrote: > Actually tag will cover ganglia-web as basically web submodule is a > pointer to a particular version of ganglia-web so when you tag > monitor-core it contains pointer to right version of ganglia-web. > > I would not be in favor of putting it back in monitor-core. I think we > should really keep the pieces separate. > > If you feel package-ganglia-release is inadequate feel free to change > it ;-). > > Vladimir > > On Sat, 10 Mar 2012, Daniel Pocock wrote: > > >> 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
