On Fri, Feb 25, 2011 at 3:16 PM, Eric Firing <efir...@hawaii.edu> wrote: > On 02/25/2011 10:01 AM, John Hunter wrote: >> On Fri, Feb 25, 2011 at 1:43 PM, Ryan May<rma...@gmail.com> wrote: >>> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale<dsdal...@gmail.com> wrote: >>>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root<ben.r...@ou.edu> 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 > > Elaborating a bit: mpl historically has had a very loose management and > a free approach to changes (Thanks, John!). I think it has served us > well. The move to git permits a continuation of this style (though for > a smaller set of committers), while facilitating more structured > procedures; it doesn't force us to change, it makes it easier to use a > range of styles, as appropriate, and perhaps gently nudges us towards > more review prior to committing. > > As always, review is not a one-time opportunity. Committed changes > always can be reviewed, and new changes made as needed. > > This is evolution, not revolution.
I'll back off my assertion somewhat, and instead observe that, so far, pull requests and associated code review have been working out superbly. We are catching problems before they find their way into the official repos. People are making constructive criticism, making encouraging comments. Perhaps my original comment was too rigid, and instead I should say that the pull request/code review workflow is shaping up to be a really code thing, and I would like to advocate for its continued use. Where appropriate. :) ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
