← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/using_gatekeepers.txt

  • Committer: Martin Pool
  • Date: 2005-06-30 07:49:50 UTC
  • mto: This revision was merged to the branch mainline in revision 852.
  • Revision ID: mbp@sourcefrog.net-20050630074950-bafafe0eb0a5eb15
Add format-hidden readwrite methods

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/using_gatekeepers.txt
1
 
Using gatekeepers
2
 
=================
3
 
 
4
 
The decentralized with human gatekeeper workflow
5
 
------------------------------------------------
6
 
 
7
 
In this workflow, one developer (the gatekeeper) has commit rights
8
 
to the main branch while other developers have read-only access.
9
 
All developers make their changes in task branches.
10
 
 
11
 
.. image:: images/workflows_gatekeeper.png
12
 
 
13
 
When a developer wants their work merged, they ask the gatekeeper
14
 
to review their change and merge it if acceptable. If a change fails
15
 
review, further development proceeds in the relevant task branch
16
 
until it is good to go.
17
 
 
18
 
Note that a key aspect of this approach is the inversion of control
19
 
that is implied: developers no longer decide when to "commit/push"
20
 
changes into the central branch: the code base evolves by gatekeepers
21
 
"merging/pulling" changes in a controlled manner. It's perfectly
22
 
acceptable, indeed common, to have multiple central branches with
23
 
different gatekeepers, e.g. one branch for the current production
24
 
release and another for the next release. In this case, a task branch
25
 
holding a bug fix will most likely be advertised to both gatekeepers.
26
 
 
27
 
One of the great things about this workflow is that it is hugely
28
 
scalable. Large projects can be broken into teams and each
29
 
team can have a *local master branch* managed by a gatekeeper.
30
 
Someone can be appointed as the primary gatekeeper to merge
31
 
changes from the team master branches into the primary master
32
 
branch when team leaders request it.
33
 
 
34
 
The decentralized with automatic gatekeeper workflow
35
 
----------------------------------------------------
36
 
 
37
 
To obtain even higher quality, all developers can be required to
38
 
submit changes to an automated gatekeeper that only merges and
39
 
commits a change if it passes a regression test suite. One
40
 
such gatekeeper is a software tool called PQM.
41
 
 
42
 
.. image:: images/workflows_pqm.png
43
 
 
44
 
For further information on PQM, see https://launchpad.net/pqm.