>>> On 3/26/2007 at 9:38 AM, in message <[EMAIL PROTECTED]>, Martin Knoblauch <[EMAIL PROTECTED]> wrote: > Hi Brad, > > for the extensibility stuff, I believe we have not yet decided how to > proceed: > > - put it in 3.0 - only possible if it does not break compatibility with > existing gmond datastreams. We are very careful here. > - branch of 3.1 - needed when the core metrics array is changed > - branch of 4.0 - needed on major architectural change > > How would you personally rate the extensibility functions. > > Cheers > Martin >
The gmond extensibility is backward compatible. I have actually run both the enhanced gmond and the original 3.0.4 version of gmond in the same cluster without any problem. Since the modular metrics show up as SOURCE="GMETRICS", a 3.0.4 version of gmond doesn't know the difference. The only issue would be cross-platform compatibility in terms of the actual source code. I don't believe that I have introduced any problems but since I can't test on all platforms that are supported by Ganglia, I can't be sure. Since I haven't been around the Ganglia project for long, I am not sure what all of your policies are with regards to new development and how to integrate it with existing code. However, I can describe to you the way we do it in the Apache HTTPD project which seems to work very well. You may already have policies in place to allow for new development to happen in the same tree. If anything that I describe here works for the Ganglia project, it could probably be adapted into your existing policies. The Apache HTTPD project takes advantage of both trunk and branches. Trunk is always considered to be unstable and considered to be the next major version of the source code. In other words, trunk for the Ganglia project would be considered version 4.0. At the time when a major or minor version release is considered by the community, (ie. 3.0-beta, 3.2-beta, 4.0-beta, 4.2-beta, etc.), a stable branch is created with the base code being the rolled alpha or beta release. A STATUS file is also created and placed in the branch. I will explain what the STATUS file is for a little later. All development including enhancements and bug fixes, continues to be checked into trunk. However the concepts of Commit-Then-Review (CTR) and Review-Then-Commit (RTC) are assigned to trunk and branches. Trunk is always CTR meaning that developers are free to commit any enhancement or bug fixes to trunk at any time without formal community review (however it is always advised to post major architectural change patches to the list first). All branches are considered RTC meaning that no code can be committed to a stable branch without having been reviewed by the community and voted upon. This is to ensure backwards compatibility of all bug fixes and critical enhancement. This is where the STATUS file comes into play. The STATUS file that is tied to a particular stable branch will include "backport proposals". In other words, if a developer has fixed a bug or introduces a critical enhancement that they believe should be backported into the stable branch, they enter a backport proposal into the STATUS file of the branch. This proposal includes a brief description of what the patch is doing and a pointer into SVN trunk where the patch can be found. The developer then adds their vote to the proposal. As other members of the community (usually those with commit rights) review the patch, they add their vote to the proposal within the STATUS file. Once a proposal gains 3 positive votes with no negative votes, it is then free to be backported and committed into the stable branch. This process allows for new development to continue in trunk yet at the same time making sure that only valid and stable patches be accepted into the current release. Releases only happen from branches. As mentioned previously, when the community decides to start the release process for a new major or minor version of the software, a branch is created. This branch is stabilized through the RTC and beta release process until considered stable. Then a tag is created and a release is rolled. All releases are tagged with even minor version numbers (2.0, 2.2, 2.4, etc). All development code carries odd minor release numbers. Each beta release made from that branch carries a revision number which increases with every release. This means that a beta might go from 2.0.0 to 2.0.x and the actual release would carry 2.0.(x+1). All follow on releases of the same branch would simply continue incrementing the revision number. In the end this development process allows for development and experimentation to continue in trunk while stable releases continue to happen in branches. There is some additional overhead of patches having to flow through trunk before being committed to a stable branch, but this is just the price to pay in order to allow innovation along side of stability. As I mentioned before, the Ganglia project may already have policies in place to handle this type of thing. So before I go ahead and commit the patches that I have created into trunk, please let me know how you would like me to proceed. thanks, Brad
