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. > > specially when : > > > > * no information about what has changed is provided, so no one knows where > > to look > > There was previously a change log, I'm not sure what happened to that > > Do we just rely on the git logs (maybe a script to extract them to the > web page too)? Or should someone be obliged to make a proper report > with each release? https://github.com/ganglia/monitor-core/wiki > > * 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. > > usually package maintainers don't even bother to get involved with > > prereleases, but would be IMHO and important part of that testing if > > we are to aim for a quality final releases. > > I'm actually testing each of the 3.3.x series on OpenCSW. I hope to > have binary packages in experimental very soon for people to try. and I am sure debian has "experimental", and fedora has "rawhide" and opensuse has "tumbleweed", and there are plenty other options we could be using to widen our test base if we would just meet their requirements and ask for their help. Carlo PS. I usually test in gentoo amd64, but not sure if "~amd64" would be the right place for the packages we put as "prerelease" ------------------------------------------------------------------------------ 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
