Re: [matplotlib-devel] github devel question

[Benjamin R. <ben...@ou...>]

On Fri, Feb 25, 2011 at 2:01 PM, John Hunter <jd...@gm...> wrote:

> On Fri, Feb 25, 2011 at 1:43 PM, Ryan May <rm...@gm...> wrote:
> > On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
> >> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
> >>> Ok, I am still learning quite a bit about git, please bear with me.
> >>>
> >>> I am having difficulty completing a pull request that I opened.
> >>
> >> In general, I don't think we should close our own pull requests. It
> >> short-circuits the review process.
> >
> > Agreed in principle. However, do we as devs want to get/give reviews
> > on every change that fixes typos in the docs or fixes stupid bugs in
> > examples? I think there's a point of diminishing returns.
>
> I just want to throw out there that in the migration to github, we
> never officially said we were going to switch the development process.
>  In fact, we said the opposite. After the migration,  Jarrod suggested
> the pull request workflow as espoused in gitwash, and I am happy to
> experiment with it, but only to the extent that "it works", ie we are
> getting fast enough code reviews and pull requests closed that
> development is slowed significantly.  In our experience on sf, we
> weren't doing a good job keeping up with submitted requests by
> non-developers on the trackers, much less reviewing the core devs'
> contributions.  Let he who thinks they can keep up with MD and JJ step
> forward...
>
> JDH
>

I did a pull request for this minor change because I am still learning the
ins and outs of git and decided to make this commit in the manner I was
already familiar.

My feeling is that these pull requests are a great way to group various
commits into logical chunks.  It also makes for a good "paper" trail for all
changes.  Github provides so many useful tools surrounding them that making
direct merges without them seems almost disruptive.  I am worried that
having two different workflows may cause issues down the line.

My take is that pull requests should always be done, but we should leave it
to the discretion of the core developers whether or not they can
self-close.  This is not too different from how things were done on SF.  I
personally would send out an email for more significant changes, wait a
week, do a ping, and then self-commit if there were no comments.  For typos
and such, I did not even bother asking for reviews (although this was rare).

Just my two cents,
Ben Root

P.S. - Darren, my hat is off to you for all your work lately.  I can't thank
you enough.