High Level Workflow with bzr in a Perfect World

Overview

This is a quick description without implementation details about how things should be structured and work. Some of the automation tools to achieve this are still in work, so the description here is of the utopia we're trying to achieve. We may still have to walk through muck from time to time at the moment.

Workflow

Developer actions

System actions

For each approved merge proposal:

Benefits to the approach

The tedious task of testing and merging is removed from the developer.

Trunk is always perfect.

The person running merges isn't tempted to skip steps.

Once a branch has been approved, for the most part the developer can simply forget about it.

The process is the same for "core" people as it is for external contributors.

Assumptions

In general, these are the design principles we're working from when making tooling.

Branching

All features get their own branch.

All bugs get their own branch.

All separate and individual thoughts get their own branch.

Code commits should be gpg signed.

Branching and merging is a fundamental daily activity.

Metadata

Metadata is good.

All branches fixing a bug should be attached to the bug.

All branches implementing a blueprint should be attached to the blueprint.

Testing

Trunk should always build and pass all tests.

Trunk should always be releasable.

All automated regression testing should be run and verified pre-merge.

Automated testing should have an overall, verifiable pass/fail answer.

Merging

No one should ever push code directly to trunk. Ever.

An automated testing system should push code to trunk once it has been verified.

All code should be peer-reviewed.

It is the responsibility of the branch author to merge his branch up with trunk.

If a branch has been pushed and possibly merged into someone else's tree, that branch should never be rebased.

Wiki: BzrPerfectWorkflow (last edited 2010-07-02 18:54:18 by MontyTaylor)