>>> On 2/8/2010 at 1:39 PM, in message <20100208203937.ga22...@gentoo.org>, >>> Justin Bronder <jsbron...@gentoo.org> wrote: > On 08/02/10 20:04 +0000, Daniel Pocock wrote: >> >> >> So, why not put the "rc" or "pre" Tag into an GANGLIA_EXTRA_VERSION and >> >> embed >> >> that into the code. That way there would be no confusion about what is in >> >> the tarball. Then we could have as many testing releases before the final >> >> one. SVN tags are cheap. What am I missing? I mean, now we are confuing >> >> people with skipped "releases". >> >> >> >> >> > >> > Basically for the reasons that I mentioned above. Agreed that SVN tags >> > are > cheap but the major reasons are to reduce the number of publically available > tarballs and to make sure that the release process itself does not allow for > problems to creep into the code. By releasing exactly what we are testing, > it reduces the number of steps in the testing and release process and at the > same time ensures that an officially released tarball is exactly the same > tarball that was tested and approved by the community during the testing > period. Also remember that we haven't ever skipped a "release". We have > only skipped revision numbers. The Ganglia web site and the sourceforge > project site are still the definitive authority on what our current release > is. By simply checking those sites, there should be no question or confusion > on what our current release is. It would be a big mistake for someone to > pull a tarball from the testing download area and deploy that into their > production >> e >> > nvironment. Like every other project, the only official download area, >> > as > far as the Ganglia project is concerned, is the sourceforge down web page and > currently the latest release available on that site is 3.1.2. If, hopefully > in a few weeks, we release 3.1.6 or whatever the final revision number is, > that will become the official Ganglia release and it really doesn't matter > what happened to any of the previous revisions. >> > >> > >> >> >> I have tested on several platforms, and for 3.1.6, I provided snapshots >> every few days for other people to do testing, but one issue slipped >> through the cracks, so 3.1.7 will be released imminently to fix that. >> Maybe there needs to be a sign-off process, e.g. a RHEL user, a Solaris >> user, etc who must test the final snapshot before a tag is done, and >> maybe we should do that before 3.1.7 is tagged. >> >> I agree with Brad's point about releasing the tarball that has actually >> been tested. If we went through the process of signing-off the >> snapshot, then the process would need to be repeated for the tag too. >> >> There is another factor as well: I have been quite aggressive about >> fixing bugs and backporting minor functionality improvements. This was >> done between 3.1.2 and 3.1.3. There was then another whole bunch of >> stuff done between 3.1.5 and 3.1.6. At this stage, the intention is to >> make the minimum possible changes to provide a usable release (hopefully >> 3.1.7), and then some more pro-active bug fixing will resume again. > > > I think Martin's point is being missed here. Speaking as just a distro > maintainer, the use of rc and pre tags do provide some significant benefits. > Consider the following simplified workflow: > > - Development happens in branches/3.1.1. > - When a release is being considered, the version is updated to report > 3.1.1_rc1 and a copy of the branch is created in tags/3.1.1_rc1. > - Should bugs be found in rc1, development is again done in branches/3.1.1 > and when complete, tags/3.1.1_rc2 is created. > - And so on, until an rc is declared to be stable. Then only the version is > updated and tags/3.1.1 is created. > > If any changes that need to be backported are found in the above process, > they are committed to branches/3.1.0, and the same tagging rc process is > used. > > While a number of extra svn 'branches' are created during this process, you > can now create the multiple tarballs with no confusion as to from which svn > revision the originated from. Backporting from branch to branch should also > be fairly simple. > > This process has one major advantage. Each rc tarball can be packaged and > released by the distros for wider testing. As it stands now, that cannot be > done. For instance in Gentoo, I'd have no problem pushing rc's to overlays > that are marked for testing newer releases, but this requires the tarball > and > version to correctly change if what is packaged changes. > > > If the above came of as preachy, I apologize. Ganglia is a great product > and > this is just my suggestion.
Thanks Justin, really the one thing that you suggested and that we aren't doing is actually creating the tag in SVN. What we have been doing is whenever we create snapshots we add a fourth revision number which happens to match the SVN revision that the tarball was created from. This has the same effect as adding rc1 or rc2 to the release except we don't have to manually change the code in the headers. The bootstrapping process actually does it for us whenever we create a snapshot. But once we have tested the snapshots and determined that we are ready for a release, that is when we flip the snapshot bit off in the build files and bump the revision number. This process builds the release tarball which also has to be tested. Once the release tarball has been tested and validated, we just drop the tarball on the download site and nothing more has to be done. The take away that I get from your comment is that we should probably produce more snapshot test tarballs before finally moving to the final release tarball testing. Then hopefully these glitches that have been biting us and causing the skipped revision numbers would be worked out before we ever got that far. Our main problem still remains however and that is the lack of testing feedback (and I am guilty of that as well). When I was the release manager for version 3.1.0 thru 3.1.2, I got almost nothing in the way of testing feedback from the community either positive or negative. The more testing feedback that we can get throughout the entire development cycle, the more likely it will be that we will not have to skip a revision number due to last minute bug fixes. Brad ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
