I have update the working with git guidelines based on the above
discussions. Here is the stats of the whole of the work:
 docs/internals/contributing/committing-code.txt    |  108 ++++++++-
 .../contributing/writing-code/branch-policy.txt    |  171
-------------
 docs/internals/contributing/writing-code/index.txt |    2 +-
 .../writing-code/submitting-patches.txt            |   61 +++--
 .../contributing/writing-code/working-with-git.txt |  228 ++++++++++++
++++++
 docs/internals/git.txt                             |  198 ++++++++++++
+++
 docs/internals/index.txt                           |    2 +-
 docs/internals/svn.txt                             |  254
--------------------
 8 files changed, 566 insertions(+), 458 deletions(-)

The biggest changes to the previous work are:
  - It is not required to create "perfect" pull requests
  - It is recommended that the committer do the final squashing
  - For basic patches the suggested (though not required) workflow is:
    - create a trac ticket
    - once you have some code available, push your work to github,
announce your branch in the ticket
    - once you have something committable available, make a pull
request. Logical commits at this time are suggested.
    - based on reviews, add commits to your work, do not squash work
at this stage, this allows the reviewer easily see what you changed.
    - If it seems the work is far away of being commit quality, or the
patch author does not respond in reasonable time, the pull request
should be closed (the patch author is free to reopen after dealing
with the review issues).
  - once the work is ready for committer, the committer will rework
the history according to her judgment. Logical commits is the
suggestion, but the documentation intentionally leaves some freedom
for the committer.

I am sure there is still a lot to polish. I might have tried to change
too big portion of the docs in one go. Still, I would like to commit
what I have tomorrow, so that the sprinters at djangocon have the
possibility to use the guidelines and begin the polishing work.
Alternatively, if it is possible to build the docs and make them
available somewhere for the sprinters, I could wait for reviews from
the sprinters, then commit the code early next week. This would make
for a really good review for the guidelines.

The work is available from:
https://github.com/akaariai/django/tree/django_git_guidelines
or for compare view:
https://github.com/akaariai/django/compare/django_git_guidelines

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to