[Numpy-discussion] Hoop jumping, and other sports

Ralf Gommers ralf.gommers at gmail.com
Thu Feb 8 06:22:36 EST 2018


On Wed, Feb 7, 2018 at 11:29 PM, Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On Wed, 07 Feb 2018 14:26:37 -0700, Charles R Harris wrote:
> > I was thinking about things to do to simplify the NumPy development
> > process. One thing that came to mind was our use of prefixes on commits,
> > BUG, TST, etc. Those prefixes were originally introduced by David
> > Cournapeau when he was managing releases in order help him track commits
> > that might need backports. I like the prefixes, but now that we are
> > organized by PRs, rather than commits, the only place we really need
> them,
> > for some meaning of "need", is in the commit titles, and maintainers can
> > change and edit those without problems. So I would like to propose that
> we
> > no longer be picky about having them in the commit summary line.
>

+1 we got more picky over time, and that was never the intention. They're
still useful, but we shouldn't request rework for such a minor thing.

> Furthermore, that got me thinking that there are probably other things we
> > could do to simplify the development process. So I'd like folks to weigh
> in
> > with other ideas for simplification or complaints about nit picky things
> > that have annoyed them.
>
> For scikit-image, we've started a policy of pushing minor edits
> (spelling corrections, sentence restructuring, etc.) directly to the PR
> branch, instead of flagging those during a review (we also have a PEP8
> bot that mentions PEP8 issues, which makes the human reviews less
> nitpicky).
>

+1. Especially useful for docstring formatting, that doesn't get picked up
by a PEP8 bot

Ralf


> To avoid users having to rebase, we now squash all PRs before merge
> (and, typically, remove the commit messages).  This also means we can
> allow merges with master to exist in the PR history.  Of course, if it
> is clear that a user took particular care to hand-craft each patch we
> don't squash, but those cases seem to be in the minority.
>
> Thank you for bringing this up, Chuck; on projects with very limited
> developer hours (almost any open source project?) whatever we can do to
> lower the contribution barrier helps a great deal.
>
> Best regards
> Stéfan
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180208/e46b2369/attachment-0001.html>


More information about the NumPy-Discussion mailing list