On 22/03/2012 16:57, Carlo Marcelo Arenas Belon wrote: > On Thu, Mar 22, 2012 at 01:52:04PM +0000, Daniel Pocock wrote: >> On 22/03/2012 13:33, Carlo Marcelo Arenas Belon wrote: >>> On Wed, Mar 21, 2012 at 07:59:16PM +0100, Daniel Pocock wrote: >>>> On 21/03/12 19:48, Vladimir Vuksan wrote: >>>>> I agree with Alex. We are churning through too many versions. I would >>>>> personally be OK with overriding the existing 3.3.2 tag and going with >>>>> 3.3.2 instead of 3.3.4. >>>> >>>> Having been involved in the releases between 3.1.2 and 3.1.7, I accept >>>> some of the responsibility if people did find it problematic >>>> >>>> That is why I put out a test tarball, only tagged 3.3.3dp1, before >>>> tagging 3.3.3 - so people did have 24 hours to evaluate >>> >>> and that resulted (like in the 3.1.2 to 3.1.7 cycle) in a couple of >>> obvious issues that were found after the "release" tag was made and >>> therefore in a couple releases more. >> >> Let's not have a discussion about `obvious' issues: Ganglia is supported >> on a large number of platforms, but I'm not sure if everyone here is >> testing every platform. I've never run it on AIX or a non-Intel based >> Linux, for example. > > "obvious" here means : > > * does it has the right version? > * does it build? > * can you make a package out of it? > * does it require a flag day (compatibility or feature wise)? > > all of those SHOULD be resolved without having to bump a version number, > because it is something we should be able to test before we make a package > that is meant for public consumption. > > a version number change in a package is normally associated with changes > on features or bugs, and therefore requires more focused testing than the > above.
This relates to my comments about simplifying Ganglia Maybe we need to actually try and do less to help people packaging Ganglia Maybe we should abolish a lot of the logic in configure that tries to set CFLAGS, for example, and make that the responsibility of the packager. Then a lot of those things can never be `broken', the release manager just has to make sure the code is good, and the packagers take more responsibility for platform and distro-specific stuff. We could still maintain a list of common CFLAGS settings in a doc for people compiling their own binaries, but try to do less stuff programatically, because the release manager can never test all of it. After all, this is the approach that autotools recommend anyway: http://lists.gnu.org/archive/html/autoconf/2010-02/msg00024.html >>> * the target audience for this product are sysadmins, and so providing >>> binaries and making broader announcements (also including the >>> ganglia-users) would be recommended so that prerelease testing is >>> exhaustive. >> >> I deliberately avoided that, because it should not be seen as an >> official release yet, and it could be tiresome helping less experienced >> users evaluate it. I would prefer to suggest that those sysadmins who >> want to test bleeding edge stuff join the dev list. > > missed the point, it is not that they want to test bleeding stuff, as much > as we want them to test our bleeding stuff, so that when it gets released > to the public all issues had been ironed out. I think we need to hear what other people think about the distinction between the dev list and users list Another variation of what you propose: the pre-release tarballs advertised on the dev list, but once the tarball has been successfully packaged into a binary (e.g. my OpenCSW package in experimental), that can be announced on the users list. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
