On Wed, Feb 7, 2018 at 11:29 PM, Stefan van der Walt <stef...@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@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
