Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Thu, Jan 07, 2010 at 02:36:38PM +, Daniel Pocock wrote: then you are going to need either 2 public resources for all release managers to use consistently or a coordinate release process were the package is generated and then independently binary packages are added to it before the announcement (which also means we have to agree on what is going to be used for building those RPM packages). Not necessarily - it may be sufficient to provide some scripts that release managers can use, as long as the hostnames can be easily configured somewhere. Then the release manager just needs to have the necessary machines available, but that is not so difficult either thanks to Xen, VMware, etc. With mock[1] you probably don't need anything beyond one machine, mock basically runs rpmbuild inside a minimal chroot (which also installs for you) of a Fedora/Centos (might also be usable for Suse) release that you want and the rpm dependencies of the package. Given that most developers will have a Fedora/Centos/RHEL/Debian machine building rpms shouldn't be a problem really. Cheers, Kostas [1] http://fedoraproject.org/wiki/Projects/Mock -- 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Tue, Jan 05, 2010 at 02:42:28PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: 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. guess that if we are going to use lenny then the defaults for that distribution should be documented then as a prerequisite here since anything older won't be tested anyway? automake: 1.10 (1.10.1) autoconf: 2.61 libtool: 1.5 (1.5.26) while the last official release (3.1.2) used instead : automake: 1.9 (1.9.6) autoconf: 2.59 libtool: 1.5 (1.5.22) and the de-facto standard (CentOS 4) used instead : automake: 1.9 (1.9.2) autoconf: 2.69 libtool: 1.5 (1.5.6) - 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. will fail if any older version is used, but work also for newer versions 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. not really, all we are doing is preventing some developer to generate their own bootstrap of ganglia if they have only access to an older than 2.61 version of autoconf, even if it is very likely that 2.53 or older will be all that is really needed. if we are not providing periodic snapshots, then that developer won't be able to do any of the work he wanted to do, unless he upgrades his tools locally or gets a handle of another system where he can get a bootstrap (most likely installing debian 5 somewhere) and so we just made his life more difficult and probably even discourage him to scratch that itch. bootstrapping, doesn't mean releasing and so would expect release managers to use the versions or environment we know works, but that is something that can be done through process and documentation better than it can be done by code, hence why I suggest r2174 gets reverted. 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. the problems with the bootstrap of 3.1.2 might had been because of using a 64 bit bootstrap (as that was never seen when doing CentOS 4 x86), but if Debian 5 doesn't have that problem (we would have to confirm that the packages generated in x86 and amd64 are identical) then saying Debian 5.0 (lenny) should be enough to describe the suggested bootstrap environment. 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 agree 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. then you are going to need either 2 public resources for all release managers to use consistently or a coordinate release process were the package is generated and then independently binary packages are added to it before the announcement (which also means we have to agree on what is going to be used for building those RPM packages). 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Tue, Jan 05, 2010 at 02:42:28PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: 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. guess that if we are going to use lenny then the defaults for that distribution should be documented then as a prerequisite here since anything older won't be tested anyway? automake: 1.10 (1.10.1) autoconf: 2.61 libtool: 1.5 (1.5.26) while the last official release (3.1.2) used instead : automake: 1.9 (1.9.6) autoconf: 2.59 libtool: 1.5 (1.5.22) and the de-facto standard (CentOS 4) used instead : automake: 1.9 (1.9.2) autoconf: 2.69 libtool: 1.5 (1.5.6) - 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. will fail if any older version is used, but work also for newer versions 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. not really, all we are doing is preventing some developer to generate their own bootstrap of ganglia if they have only access to an older than 2.61 version of autoconf, even if it is very likely that 2.53 or older will be all that is really needed. if we are not providing periodic snapshots, then that developer won't be able to do any of the work he wanted to do, unless he upgrades his tools locally or gets a handle of another system where he can get a bootstrap (most likely installing debian 5 somewhere) and so we just made his life more difficult and probably even discourage him to scratch that itch. bootstrapping, doesn't mean releasing and so would expect release managers to use the versions or environment we know works, but that is something that can be done through process and documentation better than it can be done by code, hence why I suggest r2174 gets reverted. Those are good points - but while it may be easier for people to get started developing if we are not strict about this, it means they could end up committing stuff that doesn't work when bootstrapped for release. Some ideas: - should we consider using AC_PREREQ on the release branch, but not on trunk? - should we add some over-ride option to the bootstrap script? Then the developer who understands the issues has a shortcut - should we add some errors to the bootstrap script, so that if it fails, it gives verbose output suggesting the user read this thread, remove AC_PREREQ, update autotools, etc 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. the problems with the bootstrap of 3.1.2 might had been because of using a 64 bit bootstrap (as that was never seen when doing CentOS 4 x86), but if Debian 5 doesn't have that problem (we would have to confirm that the packages generated in x86 and amd64 are identical) then saying Debian 5.0 (lenny) should be enough to describe the suggested bootstrap environment. Can you conveniently test that? 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, 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? 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. 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 - any final objections/comments? 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? Do we have a list of environments that must be tested after changing autotools again? -- 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
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, Daniel Pocock wrote: a) is it preferred that we release 3.1.4 or that we release 3.1.5, or a third option, roll a 3.1.6 tarball using the same environment where 3.1.2 was bootstrapped? 3.1.2 had a bootstrapping problem which resulted on it failing to build by default on multilib amd64/i386 systems if both the 32bit and 64bit versions of the dependencies (libapr, confuse) were installed. 3.1.4 used the same bootstrapping than 3.1.1 and so was IMHO better, but because there were multiple 3.1.4 packages is probably difficult to know which one was validated, and that was AFAIK one of the reasons why it wasn't eventually released. 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 systems 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 - maybe add some check to configure that warns if a different version of autotools is detected? c) what environment should be used to bootstrap 3.2.X/trunk? the same than 3.1 so that all improvements in the build system will be tested there and then backported for stability. Not necessarily - changes can be backported and then tested on the release branch before it is frozen/tagged for a release candidate. That would allow more aggressive changes to be implemented in trunk that are not intended for backport. 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. 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. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, 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. c) what environment should be used to bootstrap 3.2.X/trunk? the same than 3.1 so that all improvements in the build system will be tested there and then backported for stability. Not necessarily - changes can be backported and then tested on the release branch before it is frozen/tagged for a release candidate. this will violate your rule of same autotools per branch but frankly I don't care as far as we allocate for the extra time that will be needed to certify the new bootstrap environment works. That would allow more aggressive changes to be implemented in trunk that are not intended for backport. trunk has several changes that are not intended for backport already and they are not intended for release either or we will have a 3.2 branch already. 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. 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. having the OpenCSW build farm as part of our test builds would be a great way to ensure Solaris users are better supported though. Carlo -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Wed, Nov 25, 2009 at 11:00:21AM +, Daniel Pocock wrote: a) is it preferred that we release 3.1.4 or that we release 3.1.5, or a third option, roll a 3.1.6 tarball using the same environment where 3.1.2 was bootstrapped? 3.1.2 had a bootstrapping problem which resulted on it failing to build by default on multilib amd64/i386 systems if both the 32bit and 64bit versions of the dependencies (libapr, confuse) were installed. 3.1.4 used the same bootstrapping than 3.1.1 and so was IMHO better, but because there were multiple 3.1.4 packages is probably difficult to know which one was validated, and that was AFAIK one of the reasons why it wasn't eventually released. 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 systems 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. c) what environment should be used to bootstrap 3.2.X/trunk? the same than 3.1 so that all improvements in the build system will be tested there and then backported for stability. 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. Carlo -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Hi all, There has been some discussion about which version of autotools to use for bootstrapping 3.1.2 was bootstrapped with automake 1.9.6 and autoconf 2.59 3.1.4 was bootstrapped with automake 1.9.2 and autoconf 2.59 Some people test an alternative tarball bootstrapped with 1.10.1 and autoconf 2.61 3.1.5 has been bootstrapped with automake 1.10.1 and autoconf 2.61 and is the same code as 3.1.4, just a different bootstrap There are a few questions now: a) is it preferred that we release 3.1.4 or that we release 3.1.5, or a third option, roll a 3.1.6 tarball using the same environment where 3.1.2 was bootstrapped? 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)? c) what environment should be used to bootstrap 3.2.X/trunk? 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. Regards, Daniel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
