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

[Joar Wandborg]

I like it. Let's talk about it on the next meeting!

On Fri, May 18, 2012 at 10:32:09AM -0500, Christopher Allan Webber wrote:
> 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
> _______________________________________________
> devel mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/devel

-- 
Joar Wandborg
wandborg.se