[Python-Dev] Helping contributors with chores (do we have to?)

Brett Cannon brett at python.org
Mon Jun 26 17:49:08 EDT 2017

[It seems to me most of this thread has gone off-topic since it now
includes what I consider a sexist comment, complaining about git, and
discussing people's credentials in terms of being able to comment on
something, I'm basically ignoring everything that came after this email as
none of that has anything to do with what Antoine is complaining about.]

On Sun, 25 Jun 2017 at 01:34 Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Sat, 24 Jun 2017 21:37:46 -0700
> Larry Hastings <larry at hastings.org> wrote:
> > On 06/24/2017 09:14 PM, Serhiy Storchaka wrote:
> > > Not only core developers make PRs for CPython. Since all non-trivial
> > > changes need to be mentioned in Misc/NEWS, blurb becomes a required
> > > tool for all committers.
> >
> > Well, no.  *Writing blurb-compatible files* becomes a required step for
> > all committers.  And blurb makes that easy.  But it's pretty easy to
> > write them by hand; that's why we pre-created the "next" directories,
> > and there are instructions in the dev guide.
> Hmm.  If it were so easy, you wouldn't have felt the need to add that
> functionality to blurb, right? :-)

Actually a good amount of blurb is to handle blowing up a Misc/NEWS file
into individual news files and then re-combining them back into a Misc/NEWS
file for release. The format also simplified over time while we refined the
design so that the file name contains the most common metadata, thus not
really needing to check the formatting as much.

> This is touching a more general problem, though.  Before GitHub, we
> (core developers) would take the patch submitted by a contributor, make
> whatever minor changes were needed (e.g. Misc/NEWS) and push the
> aggregate ourselves.  With GitHub, while it's possible to edit someone
> else's PR, it's frankly a PITA (I've tried to do it once, I don't want
> to try a second time unless GitHub makes it massively easier and less
> footgunning-prone).

So there's editing a PR by adding/removing files and then there's editing
files that have already been touched by the PR. In the latter case you can
just edit the files through a browser while reviewing them no problem (I do
this regularly rather than ask a PR submitter to fix e.g. a spelling
mistake, just click the pencil icon at the top-right corner of the diff for
the file).

In the former case where you want to add/delete a file is where it's less
obvious on how to do it. Donald has said how to pull down a pull request as
a branch in your clone, editing, and then pushing again. But it turns out
you can *also* do it entirely through the web UI. For instance, if you look
at your https://github.com/pitrou/cpython/tree/signal_pyatomic branch you
had for your https://github.com/python/cpython/pull/2417 PR (sorry about
that, but I needed someone's branch to test with that wasn't my own), you
will see I created and deleted a news file, and I did that entirely through
my browser. The biggest pain, though, is navigating back to someone's
branch as I don't think there's a direct link to be found in a PR back to
the repo:branch it's based on.

IOW everything you used to do by hand can still be done by hand, just
through a web browser ... on a tablet at the beach with WiFi (which was one
of my goals of this whole transition to begin with :) .

> So we have to rely on contributors to make the PR
> merge-ready by themselves... which means spending some time guiding
> them through the oh-so-exciting steps necessary to add the right
> Misc/NEWS entry,

My hope is that having a news entry status check through Bedevere with help
with that. I'm also open to ideas on how to make it more obvious to
first-time contributors that things need to be done, e.g. maybe a default
PR message that is nothing more than "<!-- FIRST-TIME CONTRIBUTORS: make
sure to visit the CONTRIBUTING link above as CPython deviates from typical
GitHub practices. -->" (making it an HTML comment means it won't' ever show
up in the rendered output of the PR, plus that comment is short and thus
easy to ignore)? We could also make the CONTRIBUTING.md file have a
bullet-point list of the key things we expect people to do that is
different from most projects. (The only other thing I can think of is a
comment for first-time contributors pointing all of this out, but I'm leery
of that as all of our bots are stateless and this would make at least
Bedevere stateful.)

And if you want to make it easier to add/remove files in a PR, we could
look at adding a link to the branch the PR comes from so that it's easy to
get to to do things like add a news file through the browser.

If any of this sounds reasonable we can discuss it over on core-workflow.

> or fix the occasional bit of reStructuredText
> mis-syntax.
You can make those sorts of changes in the browser yourself.


> Regards
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170626/43afbd1f/attachment-0001.html>

More information about the Python-Dev mailing list