launchpad development
User Stories
Single Developer Project
Every once in a while, Paul gets a random contribution to a project that he works on by himself. Managing those merges is pretty simple, since he only has one branch that he works on. He merely merges the proposed branches in as he works on other issues. He does not need a merge queue at all.
Small development Project
Tarmac has a few main contributors. The development focus branch is owned by a team, but no one commits directly to it. It's contributors have rules for reviews and landings. Paul gets tired of landing each contribution himself, but it only makes sense to have a point of all the merges. A queue is then set up to manage landings into trunk.
When a review is complete, it can be queued for merging by any person who has "write" permissions to the branch. The source branch is then added to the merge queue for the target branch. Since Tarmac manages merges on the assigned queue, it will periodically look at the queue and merge branches.
On a normal interval, Tarmac will look at the merge queue (through the Launchpad API) and automatically handle merges in the queue.
Failed merge
If Tarmac fails to merge the branch, it will remove the entry from the merge queue and comment on the merge proposal with the failure message. It is then left to the user to handle the issue and then get the merge queued again.
Multiple branch development
Bazaar has many contributions every day, across two release series branches and trunk. It is simply unrealistic to expect someone to manage the merging of all of these branches and still maintain quality. In this case, the merge queue will be set up to manage these multiple branches.
When $BAZAAR_RELEASE_MANAGER cuts a release of Bazaar, he/she will
Questions
- Could we store a json string of configuration for Tarmac in the merge queue items?
- Should Tarmac dequeue the branch when it's completed, or should we have Launchpad do that?
