SVN Policy and Access Changes

FYI, as part of an effort to better audit and control what is going into the source code, as well as better organize the development efforts, I have just recompiled the SVN access control lists with a little more restrictive commit access for everyone on the team. Here’s an outline of the changes and how I’d like to handle this until I can more thoroughly formalize these policies and procedures:

[*] There are three groups of access defined, MODx Contributors, MODx Developers, and MODx Committers. Committers have full write access to everything, Developers have write access to tattoo/branches/ and tattoo-assets/, and contributors have write access only to tattoo-assets/ and their own branch.
[*] Direct commits to trunk are now forbidden to everyone; all work is to be done in either a private or shared branch; urgent exceptions can go through designated MODx Committers.
[*] When commits to branches are made with the intention of having it merged into trunk, you must merge the current trunk HEAD revision back to your branch (if any changes have been made to trunk since you last copied or merged), resolve any conflicts, and test that merge result before notifying the team that it is ready for inclusion in trunk.
[*] You will notify the team when an atomic feature or bug fix is ready to merge through a private forum, with as much detail as possible on the change (details that cannot be derived from SVN itself). This will give the core team a chance to review and/or discuss the changes before they are committed. Generally at least 48hrs should pass before the commit is made to trunk, but this can be suggested and dealt with based on the urgency of each change.

I think it makes a lot of sense to have a joint branch that can be updated by the folks that’ve been frequently committing... will make merges a lot easier too!

I agree with both posts; if groups of contributors want to use one developer’s "private" branch then Ryan’s timesaver can be applied to Jason’s outline without any additional policy changes.
This ties in with another point, which is it should be made clear that people who are not able to use SVN for whatever reason can get things in via someone else’s private branch.

Basically, everything goes through private branches, it just doesn’t have to be your own private branch. Whoever’s private branch it is would do the actual branch updating and would have final responsibility for testing etc, but the branch testing can (and in major cases really should) be tested by a group not just one individual.

I’m very pleased to see these changes; whilst breaking the 2000 barrier in commit #s can be spun well for marketing, there’s a worrying number of things that have been broken.

Such a change should also make SVN more stable, making it easier for us to release regular point upgrades. I really don’t want to see a repeat of the situation with 0.9.2.1 where it languished for months as the official install despite containing several known bugs and outdated snippets.