Notes on committing changes 0.4.2+ from Alex

0.4.2 Check-in process:

If a bug has been accepted for 0.4.2, you may check changes related to the fix for that bug into the 0.4 branch. 0.4.2 will be released out of this branch, so if your changes are not merged here,they won't be part of the release. The post-commit hook has been modified to send mail notifications about this branch.

If you do not have a ticket accepted for the release, you may not check into the branch. When in doubt, send Alex mail.

0.9-1.0 Check-in process:

The 0.4.x line will live a good, long life as our last monolithic release. Once the split is made the process will look like this:

• New, major development should happen in branches. Instead of the current system where trunk is unstable and we stabilize in a branch, this will be inverted.

• *ALL* checkins to trunk will require a ticket reference and the name of the approver/reviewer. This will be enforced by a pre-commit hook.

• A post-commit hook will also be providing "size blame" and "size win" warnings for things that significantly alter the size of builds.

• Releases will be made directly out of trunk. Checkin and freeze policy when releases get near are up to the various project leads, but in general the combination of requiring tickets and review should help keep trunk more stable than not thruought the whole release cycle.

Until we have a canonical (and hosted) test infrastructure, it's not going to be possible to do "build blame" notifications, although it's clearly desireable.