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. -- Justin Bronder
pgpZDTSofodhc.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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