i just added brad to the list of developers with write access to our subversion repository. welcome to the team, brad!
i've created a branch called "monitor-core-3.0-beta" for 3.0.x development from what is currently in trunk. we might not need quite as rigorous a process as apache but i think we need to start using branches for development. all 3.0.x code development should be out of ./tags/monitor-core-3.0-beta instead of trunk. just as before, with each new release we'll create a branch called monitor-core-3.0.n. we should keep the trunk open for more creative and radical play. i recommend that brad put his updates into the trunk for members to start testing. the sooner we do this the better because it will help us decide where to put the new code once it's fleshed out (monitor-core-3.0-beta 3.1-beta or elsewhere). does that seems reasonable martin et al? i don't want to hold up brad's new code and now our current 3.0 branch is safely isolated. since we don't have a formal voting mechanism, i suggest that if we don't hear objections by wednesday of this week.. the trunk is open for brad to drop in his enhancements. i really hope though that others chime in on their thoughts on this. -matt On Mon, 2007-03-26 at 11:21 -0600, Brad Nicholes wrote: > >>> 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 >
