/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/HACKING.txt

  • Committer: Jelmer Vernooij
  • Date: 2010-03-21 21:39:33 UTC
  • mfrom: (5102 +trunk)
  • mto: This revision was merged to the branch mainline in revision 5143.
  • Revision ID: jelmer@samba.org-20100321213933-fexeh9zcoz8oaju2
merge bzr.dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/HACKING.txt
62
62
to involving the community before you spend much time on a change.
63
63
These include:
64
64
 
65
 
* you get to build on the wisdom on others, saving time
 
65
* you get to build on the wisdom of others, saving time
66
66
 
67
67
* if others can direct you to similar code, it minimises the work to be done
68
68
 
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
---------------------------------
680
688
``only_raises`` decorator (from ``bzrlib.decorators``) for methods that
681
689
are typically called in ``finally`` blocks, such as ``unlock`` methods.
682
690
For example, ``@only_raises(LockNotHeld, LockBroken)``.  All errors that
683
 
are unlikely to be a knock-on failure from an previous failure should be
 
691
are unlikely to be a knock-on failure from a previous failure should be
684
692
allowed.
685
693
 
686
694
 
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
 
1010
1020
finish the progress task when it exits, because it may otherwise be a long
1011
1021
time until the finally block runs.
1012
1022
 
 
1023
https://wiki.ubuntu.com/UnitsPolicy provides a good explanation about
 
1024
which unit should be used when. Roughly speaking, IEC standard applies
 
1025
for base-2 units and SI standard applies for base-10 units::
 
1026
* for network bandwidth an disk sizes, use base-10 (Mbits/s, kB/s, GB),
 
1027
* for RAM sizes, use base-2 (GiB, TiB).
 
1028
 
1013
1029
 
1014
1030
Displaying help
1015
1031
===============
1147
1163
 * new features - should be brought to their attention
1148
1164
 * bug fixes - may be of interest if the bug was affecting them, and
1149
1165
   should include the bug number if any
1150
 
 * major documentation changes
 
1166
 * major documentation changes, including fixed documentation bugs
1151
1167
 * changes to internal interfaces
1152
1168
 
1153
1169
People who made significant contributions to each change are listed in
1154
1170
parenthesis.  This can include reporting bugs (particularly with good
1155
1171
details or reproduction recipes), submitting patches, etc.
1156
1172
 
 
1173
To help with merging, NEWS entries should be sorted lexicographically
 
1174
within each section.
 
1175
 
1157
1176
Commands
1158
1177
--------
1159
1178