Carlo Marcelo Arenas Belon wrote: > 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). > >
I've had a quick search for information on this - it appears that adding AC_PREREQ(2.61) would cause bootstrapping to fail on any older or newer version - only 2.61 would be supported. I think this is the right way to go, as it will prevent us from running in to the same issues again, and it will hopefully prevent people building trunk with a different version of autotools and creating bugs that no one else can re-produce. >>>>>> 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. > > Access to that box probably isn't necessary, most people should have little difficulty getting their hands on a copy of lenny, and it is easy to install - any other comments on this? >>>> 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? > I'm using lenny amd64 (64 bit) most of the time now, especially since the various browser plugins (e.g. Java) now support 64 bit Linux. > >> 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. > > Providing RPMs is probably much less important than having a stable bootstrap environment However, it would be good for packaging activities to continue, and I can't see why we can't script the release process so that it invokes the rpmbuild commands on a Fedora box over ssh. > 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. > > If we do that, are any other issues left outstanding? > tagging 3.1.6 then could be done fairly quickly after the showstoppers > and other pending cleanups are completed. > > I believe I have addressed most of them - what is outstanding now? >> 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
