/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/code-review.txt

  • Committer: Marius Kruger
  • Date: 2010-07-10 21:28:56 UTC
  • mto: (5384.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 5385.
  • Revision ID: marius.kruger@enerweb.co.za-20100710212856-uq4ji3go0u5se7hx
* Update documentation
* add NEWS

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/code-review.txt
1
 
Reviewing proposed changes to Breezy
 
1
Reviewing proposed changes to Bazaar
2
2
####################################
3
3
 
4
 
All non-trivial code changes coming in to Breezy are reviewed by someone else.
 
4
All non-trivial code changes coming in to Bazaar are reviewed by someone else.
5
5
 
6
 
Anyone is welcome to review any patch.  You don't need to have a full
 
6
Anyone is welcome to review any patch.  You don't need to have a full 
7
7
understanding of the codebase to find problems in the code, the documentation,
8
8
or the concept of the patch.
9
9
 
10
10
Normally changes by core contributors are reviewed by one other core
11
11
developer, and changes from other people are reviewed by two core
12
 
developers.  Use intelligent discretion about whether the patch is trivial.
13
 
 
14
 
No one likes their merge requests sitting in a queue going nowhere: this
15
 
is pure waste.  We prioritize reviewing existing proposals.
16
 
 
17
 
We do all our code reviews through Launchpad's merge proposal interface.
 
12
developers.  Use intelligent discretion about whether if the patch is trivial.
 
13
 
 
14
No one likes their merge requests sitting in a queue going nowhere: this 
 
15
is pure waste.  We prioritize reviewing existing proposals.  
 
16
Canonical dedicates some staff time to providing prompt helpful reviews.  
 
17
(See <http://wiki.bazaar.canonical.com/PatchPilot/>.)
 
18
 
 
19
From late 2009 on, we do all our code reviews through Launchpad's 
 
20
merge proposal interface.
18
21
 
19
22
 
20
23
Reviewing proposed changes
45
48
New things can easily be recorded in the bug tracker instead.
46
49
 
47
50
It's normally much easier to review several smaller patches than one large
48
 
one.  You might want to submit a preparatory patch that will make your "real"
49
 
change easier.
 
51
one.  You might want to use ``bzr-loom`` to maintain threads of related
 
52
work, or submit a preparatory patch that will make your "real" change
 
53
easier.
50
54
 
51
55
 
52
56
Checklist for reviewers
62
66
  blackbox (command-line level) and API-oriented tests?
63
67
 
64
68
* If this change will be visible to end users or API users, is it
65
 
  appropriately documented in release notes and/or in whats-new ?
 
69
  appropriately documented in NEWS?
66
70
 
67
 
* Does it meet the `coding standards <code-style.html>`_?
 
71
* Does it meet the coding standards below?
68
72
 
69
73
* If it changes the user-visible behaviour, does it update the help
70
74
  strings and user documentation?
81
85
Anyone can propose or comment on a merge proposal just by creating a
82
86
Launchpad account.
83
87
 
84
 
From <https://code.launchpad.net/brz/+activereviews> you can see all
 
88
From <https://code.launchpad.net/bzr/+activereviews> you can see all
85
89
currently active reviews, and choose one to comment on.  This page also
86
90
shows proposals that are now approved and should be merged by someone with
87
91
PQM access.
94
98
Landing approved changes
95
99
========================
96
100
 
97
 
Once a merge proposal is approved and finished, it's marked as
98
 
Approved and picked up by the CI (https://ci.breezy-vcs.org/),
99
 
which will automatically test and integrate it.
 
101
Once a merge proposal is approved and finished, it's sent to PQM (the patch
 
102
queue manager) which will automatically test and integrate it.  The recommended
 
103
way to start this off is by running the ``feed-pqm`` script from 
 
104
<https://launchpad.net/hydrazine/>.