~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2006-11-02 10:20:19 UTC
  • mfrom: (2114 +trunk)
  • mto: This revision was merged to the branch mainline in revision 2119.
  • Revision ID: mbp@sourcefrog.net-20061102102019-9a5a02f485dff6f6
merge bzr.dev and reconcile several changes, also some test fixes

Show diffs side-by-side

added added

removed removed

Lines of Context:
78
78
There are some common requirements in the library: some parameters need to be
79
79
unicode safe, some need byte strings, and so on. At the moment we have
80
80
only codified one specific pattern: Parameters that need to be unicode
81
 
should be checked via 'bzrlib.osutils.safe_unicode'. This will coerce the
 
81
should be checked via ``bzrlib.osutils.safe_unicode``. This will coerce the
82
82
input into unicode in a consistent fashion, allowing trivial strings to be
83
83
used for programmer convenience, but not performing unpredictably in the
84
84
presence of different locales.
85
85
 
 
86
 
 
87
Copyright
 
88
---------
 
89
 
 
90
The copyright policy for bzr was recently made clear in this email (edited
 
91
for grammatical correctness)::
 
92
 
 
93
    The attached patch cleans up the copyright and license statements in
 
94
    the bzr source. It also adds tests to help us remember to add them
 
95
    with the correct text.
 
96
 
 
97
    We had the problem that lots of our files were "Copyright Canonical
 
98
    Development Ltd" which is not a real company, and some other variations
 
99
    on this theme. Also, some files were missing the GPL statements.
 
100
    
 
101
    I want to be clear about the intent of this patch, since copyright can
 
102
    be a little controversial.
 
103
    
 
104
    1) The big motivation for this is not to shut out the community, but
 
105
    just to clean up all of the invalid copyright statements.
 
106
    
 
107
    2) It has been the general policy for bzr that we want a single
 
108
    copyright holder for all of the core code. This is following the model
 
109
    set by the FSF, which makes it easier to update the code to a new
 
110
    license in case problems are encountered. (For example, if we want to
 
111
    upgrade the project universally to GPL v3 it is much simpler if there is
 
112
    a single copyright holder). It also makes it clearer if copyright is
 
113
    ever debated, there is a single holder, which makes it easier to defend
 
114
    in court, etc. (I think the FSF position is that if you assign them
 
115
    copyright, they can defend it in court rather than you needing to, and
 
116
    I'm sure Canonical would do the same).
 
117
    As such, Canonical has requested copyright assignments from all of the
 
118
    major contributers.
 
119
    
 
120
    3) If someone wants to add code and not attribute it to Canonical, there
 
121
    is a specific list of files that are excluded from this check. And the
 
122
    test failure indicates where that is, and how to update it.
 
123
    
 
124
    4) If anyone feels that I changed a copyright statement incorrectly, just
 
125
    let me know, and I'll be happy to correct it. Whenever you have large
 
126
    mechanical changes like this, it is possible to make some mistakes.
 
127
    
 
128
    Just to reiterate, this is a community project, and it is meant to stay
 
129
    that way. Core bzr code is copyright Canonical for legal reasons, and
 
130
    the tests are just there to help us maintain that.
 
131
 
 
132
 
86
133
Documentation
87
134
=============
88
135
 
209
256
> factory, then yes, foo_factory is what I would use.
210
257
 
211
258
 
 
259
Registries
 
260
----------
 
261
 
 
262
Several places in Bazaar use (or will use) a registry, which is a 
 
263
mapping from names to objects or classes.  The registry allows for 
 
264
loading in registered code only when it's needed, and keeping
 
265
associated information such as a help string or description.
 
266
 
 
267
 
212
268
Lazy Imports
213
269
------------
214
270
 
227
283
  from bzrlib import (
228
284
     errors,
229
285
     transport,
230
 
     foo as bar,
 
286
     revision as _mod_revision,
231
287
     )
232
288
  import bzrlib.transport
233
289
  import bzrlib.xml5
234
290
  """)
235
291
 
236
292
At this point, all of these exist as a ``ImportReplacer`` object, ready to
237
 
be imported once a member is accessed.
 
293
be imported once a member is accessed. Also, when importing a module into
 
294
the local namespace, which is likely to clash with variable names, it is
 
295
recommended to prefix it as ``_mod_<module>``. This makes it clean that
 
296
the variable is a module, and these object should be hidden anyway, since
 
297
they shouldn't be imported into other namespaces.
238
298
 
239
299
 
240
300
Modules versus Members
307
367
 
308
368
Writing tests
309
369
=============
 
370
 
310
371
In general tests should be placed in a file named test_FOO.py where 
311
372
FOO is the logical thing under test. That file should be placed in the
312
373
tests subdirectory under the package being tested.
341
402
    command changes its name or signature. Ideally only the tests for a
342
403
    given command are affected when a given command is changed.
343
404
 
 
405
 4. If you have a test which does actually require running bzr in a
 
406
    subprocess you can use ``run_bzr_subprocess``. By default the spawned
 
407
    process will not load plugins unless ``--allow-plugins`` is supplied.
 
408
 
 
409
 
344
410
Doctests
345
411
--------
346
412