Changeset 4203
- Timestamp:
- 12/14/06 15:02:30 (2 years ago)
- Files:
-
- django/trunk/docs/contributing.txt (modified) (5 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/contributing.txt
r4191 r4203 50 50 cases, etc. This means including a clear, concise description of the 51 51 problem, and a clear set of instructions for replicating the problem. 52 A minimal example that illustrates the bug in a nice small test case 52 A minimal example that illustrates the bug in a nice small test case 53 53 is the best possible bug report. 54 54 … … 126 126 it obvious that the ticket includes a patch, and it will add the ticket 127 127 to the `list of tickets with patches`_. 128 129 * The code required to fix a problem or add a feature is an essential part 128 129 * The code required to fix a problem or add a feature is an essential part 130 130 of a patch, but it is not the only part. A good patch should also include 131 131 a regression test to validate the behavior that has been fixed (and prevent 132 the problem from arising again). 133 134 * If the code associated with a patch adds a new feature, or modifies behavior 132 the problem from arising again). 133 134 * If the code associated with a patch adds a new feature, or modifies behavior 135 135 of an existing feature, the patch should also contain documentation. 136 136 … … 148 148 ============= 149 149 150 Unfortunately, not all bug reports in the `ticket tracker`_ provide all 150 Unfortunately, not all bug reports in the `ticket tracker`_ provide all 151 151 the `required details`_. A number of tickets have patches, but those patches 152 152 don't meet all the requirements of a `good patch`_. 153 153 154 154 One way to help out is to *triage* bugs that have been reported by other users. 155 Pick an open ticket that is missing some details, and try to replicate the 155 Pick an open ticket that is missing some details, and try to replicate the 156 156 problem. Fill in the missing pieces of the report. If the ticket doesn't have 157 157 a patch, create one. … … 160 160 patch with all the required features, e-mail `django-developers`_. Indicate 161 161 that you have triaged a ticket, and recommend a course of action for dealing 162 with that ticket. 162 with that ticket. 163 163 164 164 At first, this may require you to be persistent. If you find that your triaged … … 388 388 -------------- 389 389 390 To test a given branch, you can simply check out the entire branch, like so:: 390 To use a branch, you'll need to do two things: 391 392 * Get the branch's code through Subversion. 393 394 * Point your Python ``site-packages`` directory at the branch's version of 395 the ``django`` package rather than the version you already have 396 installed. 397 398 Getting the code from Subversion 399 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 400 401 To get the latest version of a branch's code, check it out using Subversion:: 391 402 392 403 svn co http://code.djangoproject.com/svn/django/branches/<branch>/ 393 404 394 Or, if you've got a working directory you'd like to switch to use a branch, 395 you can use:: 405 ...where ``<branch>`` is the branch's name. See the `list of branch names`_. 406 407 Alternatively, you can automatically convert an existing directory of the 408 Django source code as long as you've checked it out via Subversion. To do the 409 conversion, execute this command from within your ``django`` directory:: 396 410 397 411 svn switch http://code.djangoproject.com/svn/django/branches/<branch>/ 398 399 ...in the root of your Django sandbox (the directory that contains ``django``,400 ``docs``, and ``tests``).401 412 402 413 The advantage of using ``svn switch`` instead of ``svn co`` is that the 403 414 ``switch`` command retains any changes you might have made to your local copy 404 of the code. It attempts to merge those changes into the "switched" code. 415 of the code. It attempts to merge those changes into the "switched" code. The 416 disadvantage is that it may cause conflicts with your local changes if the 417 "switched" code has altered the same lines of code. 418 419 (Note that if you use ``svn switch``, you don't need to point Python at the new 420 version, as explained in the next section.) 421 422 .. _list of branch names: http://code.djangoproject.com/browser/django/branches 423 424 Pointing Python at the new Django version 425 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 426 427 Once you've retrieved the branch's code, you'll need to change your Python 428 ``site-packages`` directory so that it points to the branch version of the 429 ``django`` directory. (The ``site-packages`` directory is somewhere such as 430 ``/usr/lib/python2.4/site-packages`` or 431 ``/usr/local/lib/python2.4/site-packages`` or ``C:\Python\site-packages``.) 432 433 The simplest way to do this is by renaming the old ``django`` directory to 434 ``django.OLD`` and moving the trunk version of the code into the directory 435 and calling it ``django``. 436 437 Alternatively, you can use a symlink called ``django`` that points to the 438 location of the branch's ``django`` package. If you want to switch back, just 439 change the symlink to point to the old code. 440 441 If you're using Django 0.95 or earlier and installed it using 442 ``python setup.py install``, you'll have a directory called something like 443 ``Django-0.95-py2.4.egg`` instead of ``django``. In this case, edit the file 444 ``setuptools.pth`` and remove the line that references the Django ``.egg`` 445 file. Then copy the branch's version of the ``django`` directory into 446 ``site-packages``. 405 447 406 448 Official releases
