On Sun, Aug 17, 2008 at 11:41:19AM -0600, Brad Nicholes wrote: > >>> On 8/17/2008 at 2:02 AM, in message <[EMAIL PROTECTED]>, Carlo > Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > > > 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.
OK, let me spell it for you then : * we agreed the first release for 3.1 was going to be numbered 3.1.1 and that was written into the wiki page which explains how this all works. * as soon as it was obvious that we were really going to have a release (by enforcing a feature freeze and kicking for next release proposals that were waiting for votes almost since the 3.1 branch was created) a debate was started about what the right number for this release should be, and which later resulted after some uncertainty in a package for 3.1.0 getting tagged for testing and then released 2 weeks later. * more than a week after that release the wiki page you referred to still said the first release was going to be 3.1.1 so it was corrected. > >> 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. Again let me spell it for you then : * We released countless snapshots (none of them as 3.1.0) for testing for almost 4 months and since the branch was created, each one with a different feature list because there was no feature freeze. * 2 weeks before the official release date, a feature freeze was forced and a package was released just like we were supposed to do originally. * No problems were reported during those 2 weeks and due to to lack of feedback it was assumed to be stable and it was officially released as 3.1.0. This is pretty much the same release scheme (except for the 2 weeks of waiting) that was used for 3.0 and that resulted in 3.0.7 being released to fix problems introduced with 3.0.6 and 3.0.8 being scheduled to be released at least partially to fix problems introduced in 3.0.7. Needless to say this was probably one of the main motivations why we agreed to replace that scheme for the new scheme written in the wiki instead (which was originally designed by apache and has been since abandoned by them) > >> 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 For the apache httpd server it might be, as they don't have release names by design. Ganglia in the other hand has release names as well (even if they are never really used for anything relevant) and so as shown by the final output of your configure (or http://ganglia.info/) the release version/name combination is used to uniquely identify the package. If you are arguing that release names are useless anyway, I agree and that is why that had been removed from trunk already with revision 1703. > >> 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. Agree that a 3.1.1 is expected to be released soon after 3.1.0, as real world usage uncovers all bugs and feature requests that weren't seen during testing, but you seem to be forgetting that 3.1.1 is getting released mainly (by your own words) to fix a showstopper bug that sneaked into 3.1.0 and was so expected to work that is even documented by our upgrading instructions (which I'll have to presume were never tested) therefore we are again rushing to push out any features/fixes that were scheduled to be merged with this release and that we hadn't been able to vote for yet. > So what would be a good testing period? for a stable release and based on data from the last release maybe 3 weeks (unless we only need 1 and all those showstopper bugs were uncovered after the real testing started when the release was done, but that should be better answered by the reporters of those bugs) as I mentioned before, will be important to leave some time for packagers to produce binaries so that testing is effective and for that I'd have to defer to Kostas and Stu (both CC) or any other packager for their own time estimations. > History showed that testing snapshots and tarballs were produced months > in advance of the 3.1.0 release with no testing feedback either. snapshots should NEVER be used for general testing feedback, except of course for specific feature testing and as an aid to get usable packages in the hands of willing testers instead of forcing everyone to become a ganglia developer. indeed, our documentation in the wiki, clearly explains how the process of getting a package released REQUIRES a stable package for testing, and history has shown that doing otherwise just results in depleting the few testing resources that we have available and the false sense that "someone else" has already done the testing we depend on and therefore all our use cases are covered. this of course also requires that we explain to anyone that will test ganglia where to look (after all ganglia is a little more complex to test than some web server you can run in your own desktop) and hopefully we will have more success next time so that we don't have to do yet again rush a 3.1.2 release (which has already several interesting features/bug fixes scheduled for, some of them it might seem waiting in bugzilla since 2.5.7). Carlo ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
