On Tue, Jan 05, 2010 at 02:42:28PM +0000, Daniel Pocock wrote: > 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: >>>> >>>>> 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 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? no showstoppers AFAIK; Brad will have to do the package though or provide with the specifications required to replicate whatever he did for 3.1.2. >> 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? from my point of view (and based on the tests done and recent development) : * decide if PCRE support stays or gets kicked out of this release * if stays, backport all known bugs on it and the ones in multicpu that are linked to it or prepare for a bug fix oriented 3.1.7 soon after. * if stays, decide on what else that is pending should be backported as well since we are obviously going to have to test this release longer anyway and might make sense to do them all at once, specially considering that 3.0.8 is long overdue as well and currently blocked by the 3.1 releases. * if more features are to be backported check for bug fixes (ex: r2126, r2153, r2154) that were otherwise blocked by the previous "release freeze". * if no more features are to be backported check for build related bugfixes still pending (ex: r2148, r2159), and documentation. * decide on proposed suggestion for bind/bind_hostname in udp_send_channel [1], since it is undocumented it could be changed in an incompatible way anyway with 3.1.7, so that is IMHO not a showstopper * investigate/resolve a bug on the lowercase hostname in gmetad feature where if used on a hierarchical configuration would also affect the cluster names but since that is disabled by default and the broken contrib hasn't been backported is IMHO not a showstopper either as it could be fixed later as no one will be most likely using it anyway. * some more bootstrapping related patches (ex: r2144) that I was hoping to test and release so that they can all be backported into 3.0 to make all releases from now on consistent, but then again not a showstopper. [1] http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg05367.html 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
