Hi Matt, --- Matt Massie <[EMAIL PROTECTED]> wrote:
> i just added brad to the list of developers with write access to our > subversion repository. welcome to the team, brad! > let me join you to welcome Brad to the crowd. His work looks exciting and needs to go in. > 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. That is definitely true. Lets not overdo it, but some kind of structuring of the repository is needed. > 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. > makes sense to me. 3.0.X is in a kind of maintenance mode in my opinion, so putting developement of cool stuff into trunk is OK. > 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). > see above. > 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. > No objections from me. Brad should go ahead as he sees fit. Martin > -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 > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Ganglia-developers mailing list > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
