Changeset 7745
- Timestamp:
- 06/25/08 22:59:15 (2 months ago)
- Files:
-
- django/trunk/docs/contributing.txt (modified) (8 diffs)
- django/trunk/docs/db-api.txt (modified) (3 diffs)
- django/trunk/docs/model-api.txt (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/contributing.txt
r7719 r7745 239 239 We've got two official roles here: 240 240 241 * Core developers: people with commit access who make the big decisions 241 * Core developers: people with commit access who make the big decisions 242 242 and write the bulk of the code. 243 243 … … 246 246 have been entrusted by the core developers to make some of the smaller 247 247 decisions about tickets. 248 248 249 249 Second, note the five triage stages: 250 250 … … 255 255 decision," which should be discussed either in the ticket comments or on 256 256 `django-developers`_. The "Design decision needed" step will generally 257 only be used for feature requests. It can also be used for issues 257 only be used for feature requests. It can also be used for issues 258 258 that *might* be bugs, depending on opinion or interpretation. Obvious 259 259 bugs (such as crashes, incorrect query results, or non-compliance with a … … 318 318 319 319 "worksforme" 320 Used when the the ticket doesn't contain enough detail to replicate 320 Used when the the ticket doesn't contain enough detail to replicate 321 321 the original bug. 322 322 … … 333 333 ------------------------------- 334 334 335 Although the Core Developers and Ticket Triagers make the big decisions in336 the ticket triage process, there is also a lot that general community335 Although the core developers and ticket triagers make the big decisions in 336 the ticket triage process, there's also a lot that general community 337 337 members can do to help the triage process. In particular, you can help out by: 338 338 339 * Closing "Unreviewed" tickets as "invalid", "worksforme", or "duplicate". 340 341 * Promoting "Unreviewed" tickets to "Design Decision Required" if there 342 is a design decision that needs to be made, or "Accepted" if they are 343 an obvious bug. 344 345 * Correcting the "Needs Tests", "Needs documentation", or "Has Patch" flags 339 * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate." 340 341 * Promoting "Unreviewed" tickets to "Design decision needed" if a design 342 decision needs to be made, or "Accepted" in case of obvious bugs. 343 344 * Correcting the "Needs tests", "Needs documentation", or "Has patch" flags 346 345 for tickets where they are incorrectly set. 347 346 348 347 * Checking that old tickets are still valid. If a ticket hasn't seen 349 348 any activity in a long time, it's possible that the problem has been 350 fixed , but the ticket hasn't been closed.351 352 * Contact the owners of tickets that have been claimed, but have not seen353 any recent activity. If the owner doesn't respond after a week or so, 349 fixed but the ticket hasn't yet been closed. 350 351 * Contacting the owners of tickets that have been claimed but have not seen 352 any recent activity. If the owner doesn't respond after a week or so, 354 353 remove the owner's claim on the ticket. 355 354 356 355 * Identifying trends and themes in the tickets. If there a lot of bug reports 357 about a particular part of Django, it possibly indicates that we need358 to consider refactoring that part of the code. If a trend is emerging,359 you should raise it for discussion (referencing the relevant tickets)360 on`django-developers`_.361 362 However, we do ask th at as a general community member working in the363 t icket database:364 365 * Please **don't** close tickets as "wontfix ". The core developers will366 make the final determination of the fate of a ticket, usually after 356 about a particular part of Django, it may indicate we should consider 357 refactoring that part of the code. If a trend is emerging, you should 358 raise it for discussion (referencing the relevant tickets) on 359 `django-developers`_. 360 361 However, we do ask the following of all general community members working in 362 the ticket database: 363 364 * Please **don't** close tickets as "wontfix." The core developers will 365 make the final determination of the fate of a ticket, usually after 367 366 consultation with the community. 368 367 369 368 * Please **don't** promote tickets to "Ready for checkin" unless they are 370 *trivial* changes - for example, spelling mistakes or371 broken links in documentation.372 373 * Please **don't** reverse a decision that has been made by a core 374 developer. If you disagree with a discussion that has been made, 369 *trivial* changes -- for example, spelling mistakes or broken links in 370 documentation. 371 372 * Please **don't** reverse a decision that has been made by a core 373 developer. If you disagree with a discussion that has been made, 375 374 please post a message to `django-developers`_. 376 375 377 376 * Please be conservative in your actions. If you're unsure if you should 378 be making a change, don't make the change - leave a comment with your377 be making a change, don't make the change -- leave a comment with your 379 378 concerns on the ticket, or post a message to `django-developers`_. 380 379 … … 740 739 permission to execute ``CREATE DATABASE``. 741 740 742 If you want to run the full suite of tests, there are a number of dependencies that743 you should install:741 If you want to run the full suite of tests, you'll need to install a number of 742 dependencies: 744 743 745 744 * PyYAML_ … … 749 748 * setuptools_ 750 749 751 Of these dependencies, setuptools_ is the only dependency that is required - if752 setuptools_ is not installed, you will get import errors when running one of753 the template tests. The tests using the other libraries will be skipped if the754 dependency can't be found. 750 Of these dependencies, setuptools_ is the only dependency that is required. If 751 setuptools_ is not installed, you'll get import errors when running one of 752 the template tests. The tests using the other dependencies will be skipped if the 753 particular library can't be found. 755 754 756 755 .. _PyYAML: http://pyyaml.org/wiki/PyYAML … … 774 773 ------------ 775 774 776 Tests for apps in ``django/contrib/`` go in their respective directories ,777 in a ``tests.py`` file. (You can split the tests over multiple modules 778 by using a ``tests`` folder in the normal Python way). 775 Tests for apps in ``django/contrib/`` go in their respective directories under 776 ``django/contrib/``, in a ``tests.py`` file. (You can split the tests over 777 multiple modules by using a ``tests`` directory in the normal Python way.) 779 778 780 779 For the tests to be found, a ``models.py`` file must exist (it doesn't 781 have to have anything in it). If you have URLs that need to be782 mapped, you must addthem in ``tests/urls.py``.780 have to have anything in it). If you have URLs that need to be 781 mapped, put them in ``tests/urls.py``. 783 782 784 783 To run tests for just one contrib app (e.g. ``markup``), use the same django/trunk/docs/db-api.txt
r7717 r7745 383 383 If you pickle_ a ``QuerySet``, this will also force all the results to be 384 384 loaded into memory prior to pickling. This is because pickling is usually used 385 as a precursor to caching and when the cached querysetis reloaded, you want385 as a precursor to caching and when the cached ``QuerySet`` is reloaded, you want 386 386 the results to already be present. This means that when you unpickle a 387 387 ``QuerySet``, it contains the results at the moment it was pickled, rather … … 2041 2041 ------------------------ 2042 2042 2043 One-to-one relationships are very similar to Many-to-one relationships.2043 One-to-one relationships are very similar to many-to-one relationships. 2044 2044 If you define a OneToOneField on your model, instances of that model will have 2045 2045 access to the related object via a simple attribute of the model. … … 2054 2054 ed.entry # Returns the related Entry object. 2055 2055 2056 The difference comes in reverse queries. The related model in a One-to-one2057 relationship also has access to a ``Manager`` object ; however,that ``Manager``2056 The difference comes in "reverse" queries. The related model in a one-to-one 2057 relationship also has access to a ``Manager`` object, but that ``Manager`` 2058 2058 represents a single object, rather than a collection of objects:: 2059 2059 django/trunk/docs/model-api.txt
r7713 r7745 2023 2023 name='people_view'), 2024 2024 2025 and then using that name to perform the reverse URL resolution instead2025 ...and then using that name to perform the reverse URL resolution instead 2026 2026 of the view name:: 2027 2027 … … 2032 2032 get_absolute_url = permalink(get_absolute_url) 2033 2033 2034 More details on named URL patterns can be found in`URL dispatch documentation`_.2034 More details on named URL patterns are in the `URL dispatch documentation`_. 2035 2035 2036 2036 .. _URL dispatch documentation: ../url_dispatch/#naming-url-patterns
