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. > which probably point to the fact (which keeps getting ignored) that the > testing community for ganglia is very small (per sourceforge download > statistics they were 10 downloads for each on of those prereleases) and not > able to respond in the timeline you suggest. Agreed, and as it is a volunteer community too, please take any of my suggestions as just that: suggestions, ideas to start further discussion. > 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? > * there is no standard battery test to run, neither enough time for testers > to build their own package and deploy them in some test cluster to see > how they behave. It is a `pre-release' for 7-14 days, any longer than that, and the process would drag on forever (as happened with some of the 3.1.x series) > * 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. > * there has been obviously little testing before making the "release" tar > and so those few testers eventually get more tired as the releases keep > increasing and demanding they start from scratch each time. That is the process though - I've documented the technical steps for the release process, but there is still scope to document the testing and other release considerations on the wiki I've created another helpful page today: https://github.com/ganglia/monitor-core/wiki/ReleaseTesting and would invite people to add their test ideas there. > 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. Another suggestion: maybe it is better to simplify more: - it was decided to merge the web interface, but another idea that didn't occur to anyone (including myself) was for the new web UI to `adopt' the last released version of the old UI, and then `branch' in some sense. E.g. the version number could have been bumped up from 2.2 -> 3.3, and the legacy web directory just dropped completely from monitor-core. Call it `Identity theft' in a packaging context. This would have provided valid version numbers for seamless upgrades on packaging systems. Maybe it is not too late to do this. - maybe more of the modules can be split away, especially the python stuff, to reduce the burden of testing releases of monitor-core? Once again, start new projects with version numbers that start at the current Ganglia release + ..1 ------------------------------------------------------------------------------ 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
