>>> On 8/17/2008 at 2:02 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Sat, Aug 16, 2008 at 11:28:06PM -0600, Brad Nicholes wrote: >> >>> On 8/16/2008 at 11:26 AM, in message <[EMAIL PROTECTED]>, Carlo >> Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: >> > On Fri, Aug 15, 2008 at 11:48:50AM -0600, Brad Nicholes wrote: >> > >> >> Due mainly to the segfault patch, I am proposing that we tag and roll a >> >> testing tarball of 3.1.1 within the next week >> > >> > agree, but even if we agreed before to the process of releasing requiring >> > a tag and a stable package, I suspect (specially based on the recent > history >> > with 3.1.0) that the process will be instead : >> > >> > * release a snapshot package for testing (3.1.0.1696?) and wait for > feedback >> > * tag 3.1.1 (hopefully after no changes were required from the testing > cycle >> > and except for the required changes in configure to make it a stable >> > package) and then wait for the 2 weeks. >> >> I'm not sure why an extra snapshot is necessary. The above two steps are >> the same thing just with different revision numbers. > > and you probably already forgot how the agreed plan of skipping 3.1.0 to > avoid > getting development versions that had higher numbers than a release version > that we agreed to was scrapped at the last moment just because apparently > naming the first release of 3.1 as 3.1.0 was the "Right Thing (TM)" to do. > > don't worry I'd updated the wiki page since so that it is at least > consistent > with what we ended up doing. >
I'm not sure what this means. Using the macro number (3.1.0.1234) for development snapshots is still in place as outlined on the wiki. What we are talking about here is a testing release, not a snapshot. >> Basically the way it works, as outlined on the wiki >> (http://ganglia.wiki.sourceforge.net/ganglia_works) > > guess you mean, the way we agreed it should work (which was really just the > same scheme that apache used for the 2.0 branch of the apache server). > > agree with you though that whatever we do should be documented in that page, > but that is not the case so far, and unless we are willing to get a package > out named 3.1.1 which might had to be thrown away without ever being > released > because it has a regression on it or because a mistake was done when tagging > the branch or preparing the package (which seems to be very common) we will > never do. > Again, I am not sure where we deviated from the release documentation on the wiki. Everything that was done and is being done for future releases is consistent with the documentation. Also, the version scheme does allow for a version number to be used for a testing package and thrown away without ever being released if a regression or critical bug is found. This is by design and also how the Apache project does their releases as well. Yes, this might mean that 3.1.1 is released as a testing package but never officially released. Tags are cheap in SVN and so are revision numbers. >> a tag is created in SVN that carries the proposed release version number. >> The purpose for this is so that every release (whether official or >> unofficial testing release) can be tracked and reproducible. Then a >> tarball is rolled from the tag and posted in the ganglia testing area >> for download. > > and that is why before that tag and package is prepared, the release name > has > to be committed, otherwise the official package will had to be changed from > the one that is posted from testing. > > of course doing something as simple as getting a release name shouldn't be a > reason to delay a release but for whatever reason it has taken already more > than 2 weeks to decide since 3.1.0 was released. > Which isn't a problem because it is the version.revision number that uniquely identifies the package even if the package is determined to be unacceptable and ultimately thrown away along with the version.revision number. >> But so far there is no evidence that a two week testing period is >> insufficient. > > If you define a "testing period" as a period where we wait for "someone" to > get the package, deploy it in production and tell us why it broke his setup > then no amount of testing will be sufficient, and so choosing and arbitrary > 2 > weeks is as good as anything else, if that is what you mean. > > There is IMHO enough evidence to probe that 2 weeks is too little, unless > you > are to assume that we are not doing any testing during those 2 weeks, if you > consider that the day of the release tcpconn was reported unstable in > BUG196, and 5 days later two other showstopper bugs were reported for 3.1.0 > (BUG197 and BUG198) with at least one of them being behind why we have to > rush > to release 3.1.1 I don't consider 3.1.1 to be a rush, I consider it to be expected following a .0 release as I noted on the list prior to the 3.1.0 release. So what would be a good testing period? History showed that testing snapshots and tarballs were produced months in advance of the 3.1.0 release with no testing feedback either. So the choice is to move forward or wait. Waiting gets us no where. Moving forward especially with the 3.1.0 release has produced feedback, bugs, patches and progress towards 3.1.1 that we would have never received otherwise. I would expect 3.1.1 to be better than 3.1.0 which is good for the project and good for the user. The reaction time in fixing all of the above issues to allow a 3.1.1 release has been wonderful. I find all of the new interest and activity in the Ganglia project in the last few weeks since the 3.1.0 release, to be very refreshing, beneficial and exciting. The ball is rolling and I can't wait to see what happens with future releases as new developers get involved and new ideas start flowing (as they already have). Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
