171
172
Core developers, who ultimately merge any approved branch (from themselves,
172
173
another developer, or any third-party contribution) will typically use
173
:command:`bzr merge` to merge the branch into the trunk and push it to the main
174
Launcphad site. This is a short list of things to keep in mind when doing this
175
process, so that the project history is easy to understand in the long run, and
176
that generating release notes is as painless and accurate as possible.
178
- When you merge any non-trivial functionality (from one small bug fix to a big
179
feature branch), please remember to always edit the changes_ file
180
accordingly. This file has one main section for each release, and if you
181
edit it as you go, noting what new features, bug fixes or API changes you
182
have made, the release notes will be almost finished when they are needed
183
later. This is much easier if done when you merge the work, rather than
184
weeks or months later by re-reading a massive Bazaar log.
186
- When big merges are done, the practice of putting a summary commit message in
187
the merge is *extremely* useful. It makes this kind of job much nicer,
174
:command:`bzr merge` to merge the branch into the trunk and push it to the
175
main Launcphad site. This is a short list of things to keep in mind when doing
176
this process, so that the project history is easy to understand in the long
177
run, and that generating release notes is as painless and accurate as
180
- When you merge any non-trivial functionality (from one small bug fix to a
181
big feature branch), please remember to always edit the :file:`changes.txt`
182
file accordingly. This file has one main section for each release, and if
183
you edit it as you go, noting what new features, bug fixes or API changes
184
you have made, the release notes will be almost finished when they are
185
needed later. This is much easier if done when you merge the work, rather
186
than weeks or months later by re-reading a massive Bazaar log.
188
- When big merges are done, the practice of putting a summary commit message
189
in the merge is *extremely* useful. It makes this kind of job much nicer,
188
190
because that summary log message can be almost copy/pasted without changes,
189
191
if it was well written, rather than dissecting the next-level messages from
190
192
the individual commits.
192
194
- It's important that we remember to always credit who gave us something if
193
it's not the committer. In general, we have been fairly good on this front,
194
this is just a reminder to keep things up. As a note, if you are ever
195
it's not the committer. In general, we have been fairly good on this front,
196
this is just a reminder to keep things up. As a note, if you are ever
195
197
committing something that is completely (or almost so) a third-party
196
198
contribution, do the commit as::
198
200
$ bzr commit --author="Someone Else"
200
202
This way it will show that name separately in the log, which makes it even
201
easier to spot. Obviously we often rework third party contributions
203
easier to spot. Obviously we often rework third party contributions
202
204
extensively, but this is still good to keep in mind for cases when we don't
203
205
touch the code too much.
added
removed
docs/source/development/overview.txt
