On Mon, Dec 28, 2009 at 10:51:51PM +0000, Daniel Pocock wrote: > Carlo Marcelo Arenas Belon wrote: > > On Sun, Dec 06, 2009 at 09:28:04AM +0000, Daniel Pocock wrote: > > > >> Carlo Marcelo Arenas Belon wrote: > >> > >>> On Wed, Nov 25, 2009 at 11:00:21AM +0000, Daniel Pocock wrote: > >>> > >>>> b) should the choice of bootstrap environment be locked for all > >>>> 3.1.X, and only changed when increasing the minor version number > >>>> (e.g. when we go from 3.1 to 3.2)? > >>>> > >>> no, but since our build system is full of hacks and not completely > >>> reliable > >>> it might be a good idea to test no issues are introduced when looking at > >>> a new version. > >>> > >> Ok, but if it is not locked down, let's consider some of the following: > >> > >> - document the version we expect > > > > agree, and that is what README.SVN is for, but first we have to decide which > > version to expect to begin with. > > > >> - maybe add some check to configure that warns if a different version of > >> autotools is detected? > > > > configure doesn't depend autotools and so that would be the wrong place to > > put > > any checks, but configure.in does and there is where bootstrapping should be > > aborted using AC_PREREQ and friends if using the wrong versions. > > > Ok, should we use AC_PREREQ for 3.1.6, are there any disadvantages?
only if the macros will definitely break with an older version of autoconf as otherwise all we are doing is enforcing a recommendation and preventing anyone that might not have access to the newest version of autotools the posibility of getting their own bootstrap (not much of an issue if we also provide regular snapshots though). > >>>> d) Can anyone volunteer to provide a stable bootstrap environment > >>>> (e.g. a virtual server) just for Ganglia? Two such environments may > >>>> be needed, one for trunk and one for the current release branch. > >>>> > >>> Matt did offer an EC2 instance if we could agree on an OS version : > >>> > >>> > >>> http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg05271.html > >>> > >>> I suggested Debian 5.0 (more conservative) or Fedora 12 (to be updated > >>> more > >>> frequently) but as far as it is agreed, documented and reproducible > >>> anything > >>> should work. > >> > >> I prefer Debian 5.0 (lenny), that is what I have on my laptop, home PC > >> and various other infrastructure that I use. Elsewhere I am using > >> RHEL3/4/5. > > > > Debian 5.0 is also what is being used for bugzilla AFAIK and so that might > > be a good option for consolidation. > > Who controls access to the Bugzilla server? I wouldn't mind having use > of that as a bootstrap environment. Matt would know, but I suspect that shell access might be probably problematic to get and therefore unless we are talking about some continuous build system like cruisecontrol or hudson making snapshots, it might be problematic otherwise. to easy using one of those systems r2144 (still incomplete) was committed but would be nice to know which direction we are going anyway and for now it would seem there is not much dialogue going on about the alternatives. > >> We also have access to the OpenCSW build farm, and they are willing to > >> consider applications for access by Ganglia developers, so we could look > >> at that as a bootstrap environment. > > > > Bootstrapping is done only once per package and so wouldn't make sense to > > also do bootstrapping in Solaris. > > No, I wasn't suggesting we bootstrap separately for Solaris. I was just > suggesting that we use the OpenCSW machine to bootstrap for all platforms. > > However, we would be stuck with whatever version of autotools is current > in the OpenCSW environment, and any decision to change the version there > would be out of our control. > > I think Debian 5.0 (lenny) is the final decision then Debian 5.0 (lenny) x86 (32-bit) right? > any final objections/comments? the only one I can think of is that we sometimes used to provide RPMs with the releases but that would be IMHO not that important considering that fedora/EPEL might be the package most people would use anyway and at least for fedora that used to be released fairly quickly after the source package was posted on our site as the fedora packagers are also actively involved in the list. debian/ubuntu is usually also well represented, and that shouldn't be an issue for releases in debian 5 anyway. > Should we > > a) after fixing the other showstopper (fork issue), do we tag 3.1.6 and > let people test a tarball from Debian 5 autotools?, or > > b) make another 3.1.5 tarball using Debian 5 autotools, and put it in a > separate location for people to test before we tag? Using debian for this release will break Solaris (I have a fix ready but not yet backported) and also AIX (which Michael is maintaining outside our tree and with patched generated based on the bootstrapping used for 3.1.2) : http://www.perzl.org/ganglia/ As I said in the STATUS file for 3.1, it would be better IMHO to delay this decision until 3.1.7 (which hopefully would also include support for AIX officially) and which IMHO should be done with Debian 5, and get 3.1.6 bootstrapped with whatever Brad used for 3.1.2 instead. tagging 3.1.6 then could be done fairly quickly after the showstoppers and other pending cleanups are completed. > Do we have a list of environments that must be tested after changing > autotools again? the ones that are reported as supported currently on each release (including all supported architectures for each) : Linux (Fedora, RHEL, SLES, OpenSuSE, Debian, Ubuntu, Gentoo) [Open]Solaris FreeBSD NetBSD OpenBSD DragonFlyBSD Cygwin (no support for DSO) AIX (no support for DSO) for getting all of them validated, the easiest think will be to make a snapshot with the new autotools after 3.1.6 gets released and get that build everywhere, or do the same before 3.1.7 gets tagged so that all bootstrapping issues are resolved for that release. Carlo ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
