[IPython-dev] Outstanding pull requests

Fernando Perez fperez.net at gmail.com
Mon Feb 14 17:53:15 EST 2011


On Mon, Feb 14, 2011 at 1:32 PM, MinRK <benjaminrk at gmail.com> wrote:
> Thanks for all this great work.  I'll pitch in and merge some of these.

Many thanks!

> I just have a clarifying question for direct-commit/pull-request policy.
> For instance, I was looking at %who, and the docstrings look great, but I
> noticed that the behavior in the code is actually wrong:
>             out = [i for i in out if type(i).__name__ in typeset]
> should be:
>             out = [i for i in out if type(user_ns[i]).__name__ in typeset]
> (since `out` is the list of names, not variables, so it behaved as if
> everything had type 'str').  Which, first of all, is excellent, since
> docstrings should help us find bugs like this one has, but here's my
> question:
> What is the policy on tiny bugs like this?  Should I do a one-line
> pull-request, or just push a fix directly to master (with test, of course)?

I've always felt that a certain level of trust, and willingness to fix
little slip-ups without getting upset if/when they happen, is the best
policy.  Core developers should feel free to make small merges like
these when they are confident that there's no danger.

I realize that it's always possible to make a mistake and to have a
small change that inadvertently introduces an error.  But I also
deeply dislike 'zero tolerance' style approaches to anything, where
human thought and judgment are eliminated in favor of blind policy.

Especially since it's true that even *with* review we can still make
mistakes (and that's OK, we'll just fix them), I don't want the idea
of review to become a straitjacket that forces every last action in
the project to require six rubber stamps.  Since an absolutist policy
would be just the *illusion* of 'no mistakes', we might as well live
with the reality and find an approach that balances things to maximize
the efficiency, fluidity and the fun of working on the project for all
involved [1].

Paraphrasing the famous quote on simplicity, we need just enough
process and policy to help things run smoothly, but no more :)

So my take is: use your judgment, and when you are confident that a
*small* fix is obvious, otherwise innocuous, and that making it
directly will just save everyone time for more complex reviews, go
ahead.  When in doubt for any reason, do ask for review.  And needless
to say, large or complex changes of any kind, or even small ones that
entail important design decisions, should always be put up for review.

Cheers,

f

[1] The fun part *is* important.  As a largely volunteer effort, we
need to ensure that people *enjoy* working on IPython (myself included
:).



More information about the IPython-dev mailing list