>>> On 4/1/2007 at 10:05 AM, in message <[EMAIL PROTECTED]>, 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! >
Thanks, I really appreciate the vote of confidence. Hopefully the enhancements and patches that I have proposed so far will help the ganglia project move forward and help to serve the needs of those that are using it. > 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. > Is there a reason why you created the 3.0.x development branch in ./tags? Tags is usually designated to be the location for read-only copies of released source code. This is were most people would go to find the current or archived snapshots of the source code releases. Branches is usually where a copy of the code would go that is still in development or maintenance. Normally something like ./branches/monitor-core-3.0.x would be created and then as maintenance releases are rolled, the release snapshot would be copied to ./tags/monitor-core-3.0.<some-revision-number>. Once a tag is created for that released revision, the branch is open for continued development and maintenance. > 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. > Unless you see any reason not to, I will wait until Wednesday before I start committing the extension enhancements and other patches that I have. This should give others the opportunity to respond to your proposal before the commits start happening. Brad
