Re: [GMG-Devel] Fwd: Django git guidelines

[Christopher Allan Webber]

Forwarding to the MediaGoblin list.

We've been talking about borrowing the workflow that Django uses for its
Trac tickets and etc.

The main thing I'm interested in is switching things so that the states
actually change to more useful things like "has patch" and "ready for
checkin" and etc.

Might be worth discussing in next month's meeting?  Should we make
changes to our git and ticket workflows?

 - Chris

will kahn-greene <address@hidden> writes:

> Thought you might think this is interesting/useful.
>
> The gist of it is that Django is moving their repository to github and
> thus creating new rules for workflow to match. They're keeping their
> issue tracker in Trac.
>
> Replace "github" with "gitorious" and that's how MediaGoblin is set up.
>
> You mentioned how you liked some things they were doing in Trac. Maybe
> we should just steal the whole workflow?
>
> /will
>
>
> -------- Original Message --------
> Subject: Django git guidelines
> Date: Fri, 18 May 2012 01:43:13 -0700 (PDT)
> From: Anssi Kääriäinen <address@hidden>
> Reply-To: address@hidden
> To: Django developers <address@hidden>
>
> A heads up: I am working on Git and Github usage guidelines. There is
> a ticket https://code.djangoproject.com/ticket/18307, and I have a
> github branch with some initial work
> https://github.com/akaariai/django/tree/django_git_guidelines
> (or for changeset
> https://github.com/akaariai/django/compare/django_git_guidelines)
>
> The guidelines in short:
>  - For trivial patches use pull requests directly
>  - For non-trivial patches, create a trac ticket, announce your work
> by linking to your github branch, and when your work is ready to be
> pulled in, only then do a pull request
>  - Aim for logically contained commits, commit messages of 50 char
> summary line, 72 char paragraphs thereafter.
>  - When upstream has changed use git rebase instead of git pull
>  - When you do additional fixes to your work, use git rebase -i so
> that your work still fullfills the logical commits requirement.
>
> Lots of more details in the WIP branch. All feedback welcomed. Lets
> keep the discussion of any high-level issues here on django-
> developers, as the choices made impact the whole community.
>
> The biggest issue is how we aim to use the pull requests. My take on
> this is that pull requests should be only used for work ready for
> committer. That is, the original author feels the work is ready, or he
> doesn't know how to do anything more. If the pull requests are used
> for feature requests or work-in-progress patches we risk having lots
> of open tickets and lots of open pull requests.
>
> I have tried to gather pieces of wisdom around the net. I am not too
> experienced with Git, so if you have experience with the above
> mentioned and/or other Git workflows feedback is appreciated.
>
> - Anssi