← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/HACKING.txt

  • Committer: Robert Collins
  • Date: 2010-04-08 04:34:03 UTC
  • mfrom: (5138 +trunk)
  • mto: This revision was merged to the branch mainline in revision 5139.
  • Revision ID: robertc@robertcollins.net-20100408043403-56z0d07vdqrx7f3t
Update bugfix for 528114 to trunk.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/HACKING.txt
120
120
`your_lp_username`.  You can push your branch to Launchpad directly from
121
121
Bazaar::
122
122
 
123
 
  $ bzr push lp:~your_lp_username/bzr/giveback
 
123
  $ bzr push lp:~your_lp_username/bzr/meaningful_name_here
124
124
 
125
125
After you have pushed your branch, you will need to propose it for merging to
126
 
the Bazaar trunk.  Go to <https://launchpad.net/your_lp_username/bzr/giveback>
127
 
and choose "Propose for merging into another branch".  Select "~bzr/bzr/trunk"
128
 
to hand your changes off to the Bazaar developers for review and merging.
 
126
the Bazaar trunk.  Go to
 
127
<https://launchpad.net/your_lp_username/bzr/meaningful_name_here> and choose
 
128
"Propose for merging into another branch".  Select "~bzr/bzr/trunk" to hand
 
129
your changes off to the Bazaar developers for review and merging.
 
130
 
 
131
Using a meaningful name for your branch will help you and the reviewer(s)
 
132
better track the submission. Use a very succint description of your submission
 
133
and prefix it with bug number if needed (lp:~mbp/bzr/484558-merge-directory
 
134
for example). Alternatively, you can suffix with the bug number
 
135
(lp:~jameinel/bzr/export-file-511987).
 
136
 
129
137
 
130
138
Why make a local copy of bzr.dev?
131
139
---------------------------------
689
697
 
690
698
In some places we have variables which point to callables that construct
691
699
new instances.  That is to say, they can be used a lot like class objects,
692
 
but they shouldn't be *named* like classes:
 
700
but they shouldn't be *named* like classes::
693
701
 
694
702
> I think that things named FooBar should create instances of FooBar when
695
703
> called. Its plain confusing for them to do otherwise. When we have
723
731
those parameters, and this instance then has methods for operations
724
732
between the objects.
725
733
 
 
734
::
 
735
 
726
736
  inter = InterRepository.get(source_repo, target_repo)
727
737
  inter.fetch(revision_id)
728
738
 
1011
1021
time until the finally block runs.
1012
1022
 
1013
1023
 
 
1024
Message guidelines
 
1025
------------------
 
1026
 
 
1027
When filenames or similar variables are presented inline within a message,
 
1028
they should be enclosed in double quotes (ascii 0x22, not chiral unicode
 
1029
quotes)::
 
1030
 
 
1031
  bzr: ERROR: No such file "asdf"
 
1032
 
 
1033
When we print just a list of filenames there should not be any quoting:
 
1034
see `bug 544297`_.
 
1035
 
 
1036
.. _bug 544297: https://bugs.launchpad.net/bugs/544297
 
1037
 
 
1038
https://wiki.ubuntu.com/UnitsPolicy provides a good explanation about
 
1039
which unit should be used when. Roughly speaking, IEC standard applies
 
1040
for base-2 units and SI standard applies for base-10 units:
 
1041
 
 
1042
* for network bandwidth and disk sizes, use base-10 (Mbits/s, kB/s, GB)
 
1043
 
 
1044
* for RAM sizes, use base-2 (GiB, TiB)
 
1045
 
 
1046
 
 
1047
 
1014
1048
Displaying help
1015
1049
===============
1016
1050
 
1147
1181
 * new features - should be brought to their attention
1148
1182
 * bug fixes - may be of interest if the bug was affecting them, and
1149
1183
   should include the bug number if any
1150
 
 * major documentation changes
 
1184
 * major documentation changes, including fixed documentation bugs
1151
1185
 * changes to internal interfaces
1152
1186
 
1153
1187
People who made significant contributions to each change are listed in
1154
1188
parenthesis.  This can include reporting bugs (particularly with good
1155
1189
details or reproduction recipes), submitting patches, etc.
1156
1190
 
 
1191
To help with merging, NEWS entries should be sorted lexicographically
 
1192
within each section.
 
1193
 
1157
1194
Commands
1158
1195
--------
1159
1196