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

[Victor Stinner]

Small enhancement: I added Python 3.5 support to blurb with the help
of Serhiy Storchaka ;-)

Victor

2017-06-25 10:33 GMT+02:00 Antoine Pitrou :
> On Sat, 24 Jun 2017 21:37:46 -0700
> Larry Hastings  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? :-)
>
> 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 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, or fix the occasional bit of reStructuredText
> mis-syntax.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

On 27 June 2017 at 07:49, Brett Cannon  wrote:
> On Sun, 25 Jun 2017 at 01:34 Antoine Pitrou  wrote:
>> 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 "" (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.)

This reminded me of another relevant option for contributors making
their first drafts of NEWS entries: they/we can take an existing NEWS
snippet like 
https://github.com/python/cpython/blob/master/Misc/NEWS.d/next/Core%20and%20Builtins/2017-06-26-14-29-50.bpo-30765.Q5iBmf.rst,
save it under an appropriate filename, and then edit the content.

To be honest, I suspect that's how I'll end up writing most of my own
NEWS entries rather than using blurb to generate them :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

[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  wrote:

> On Sat, 24 Jun 2017 21:37:46 -0700
> Larry Hastings  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 "" (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.

-Brett


> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>

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

[Nick Coghlan]

On 26 June 2017 at 07:39, Paul Moore  wrote:
> On 25 June 2017 at 18:31, Donald Stufft  wrote:
>>
>> I have used it. I don’t use it every day but I’ve never had it fail on me
>> unless the contributor has unchecked the flag. I just ``git remote add
>>  `` then checkout their branch, add more
>> commits, and push to their branch.
>
> That's relatively simple, but not immediately obvious (at least to me).

This seems like a good point to remind folks that we have a "Git
Bootcamp and Cheat Sheet" as part of the developer guide:
https://docs.python.org/devguide/gitbootcamp.html

PR editing is one of the topics covered:
https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging

However, many of us editing it tend to be on Linux or Mac OS X (and
are often experienced git users as well), so issues and PRs clarifying
steps that are currently omitted, platform-specific, or otherwise
don't work as advertised are definitely appreciated.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

> On Jun 25, 2017, at 5:39 PM, Paul Moore  wrote:
> 
> On 25 June 2017 at 18:31, Donald Stufft  wrote:
>> 
>> I have used it. I don’t use it every day but I’ve never had it fail on me
>> unless the contributor has unchecked the flag. I just ``git remote add
>>  `` then checkout their branch, add more
>> commits, and push to their branch.
> 
> That's relatively simple, but not immediately obvious (at least to me).


I’m completely willing to agree that because git was the first VCS I used 
seriously (I tried Mercural out early on, but switched quickly before I got too 
deep in it b/c of Github) that my brain has successfully been broken in a git 
shaped way ;)


> 
> There's a lot of concepts in here that are not exactly basic:
> 
> 1. Being allowed to have multiple remotes in one repository
> 2. Naming of branches in non-default remotes, and how to translate the
> name in the remote to the local name you need to use
> 3. Pushing to non-default remotes
> 
> There's also the point noted that by default, github doesn't permit
> this usage, and the contributor has to explicitly allow it - which
> probably means the core dev need to know how to do it, and how to
> explain that process to the contributor.

Just a point of clarification, as far as I am aware Github defaults that 
checkmark to on, and PR authors have to explicitly turn it off to disable it. 
Although I think older PRs were all set to act as if the author did not grant 
that permission.

> 
> And probably others. I'm not interested in debating what constitutes
> stuff that "everyone should know", or how "easy" or not git is. But
> for someone coming from a familiarity with Mercurial (which means many
> core devs) the learning curve is pretty steep (I'd consider that
> self-evident, because of the differences between the 2 systems).


Not sure if this was aimed at me or not, but I don’t think that everyone should 
know that off the bat! I was just giving the steps I use to use it, hopefully 
in a useful way for other people.

—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

On 26 June 2017 at 08:20, Tim Delaney  wrote:

>
> 2. Last I checked hggit can't force-push to a git repository after
> history-modifying actions (e.g. rebase) so after such actions it's
> necessary to delete any existing branch in a local git repo, hg push to
> that then force-push to Github. This wnew branch head.
>

Not sure what happened there - that last line should have been:

This will update any PR for that branch to the new branch head.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

On 26 June 2017 at 07:39, Paul Moore  wrote:

> On 25 June 2017 at 18:31, Donald Stufft  wrote:
> >
> > I have used it. I don’t use it every day but I’ve never had it fail on me
> > unless the contributor has unchecked the flag. I just ``git remote add
> >  `` then checkout their branch, add more
> > commits, and push to their branch.
>
> The decision to move to git/github has been made. It's not up for
> debate whether core devs need to learn to deal with it. But we do need
> to acknowledge that there's a significant learning curve, and while
> core devs are contributing from their free time, learning the new
> tooling is a major distraction from what they actually want to do,
> which is work on Python code.
>

I went  through this transition a few years ago when I changed employment
(and didn't enjoy it in the slightest). Coming from Mercurial, Git feels
primitive (I mean that literally - common functionality often requires
low-level, arcane invocations). I can keep all of the Mercurial
command-line that I use regularly in my head, whereas with Git I always
have to go back to the manual even for things that I use all the time, and
I'm often unsure if I'll get the result I expect. As a result, I've avoided
using Git directly as much as possible.

Instead, my personal recommendation for people who are experienced with
Mercurial but not Git is to use Mercurial with the hggit plugin. It's not
ideal, but since Mercurial functionality is almost a superset of Git
functionality, it works so long as you don't use things that Git can't
handle.

The most important things to be aware of IMO are:

1. Avoid the use of named branches and instead use bookmarks (a workflow I
personally hate, but it's the closest match to git branches, and I know I'm
an anomaly in preferring named branches).

2. Last I checked hggit can't force-push to a git repository after
history-modifying actions (e.g. rebase) so after such actions it's
necessary to delete any existing branch in a local git repo, hg push to
that then force-push to Github. This wnew branch head.

So the workflow I use for working with Github is (after enabling hggit):

git clone  .git
hg clone git+.git 

cd .hg
...

cd .git
git branch -d  

cd .hg
hg push -B  .git

cd .git
git push --force

Although I use a Git GUI to avoid having to remember the git commands ...

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Oleg Broytman]

On Sun, Jun 25, 2017 at 10:39:36PM +0100, Paul Moore  
wrote:
> for someone coming from a familiarity with Mercurial (which means many
> core devs) the learning curve is pretty steep (I'd consider that

   I switched to git after had been using hg for about 3 years. The
first few months after the switch were rather painful. It took me a year
to start understanding git and another year to master it. But I'm a slow
thinker, I must admit.

> self-evident, because of the differences between the 2 systems).

   Not sure about self-evidence. At the first glance they look similar.
Both are DVCSes with DAG.
   The devil is in the details. In a lot of small quite different
details.

> Paul

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 25 June 2017 at 18:31, Donald Stufft  wrote:
>
> I have used it. I don’t use it every day but I’ve never had it fail on me
> unless the contributor has unchecked the flag. I just ``git remote add
>  `` then checkout their branch, add more
> commits, and push to their branch.

That's relatively simple, but not immediately obvious (at least to me).

There's a lot of concepts in here that are not exactly basic:

1. Being allowed to have multiple remotes in one repository
2. Naming of branches in non-default remotes, and how to translate the
name in the remote to the local name you need to use
3. Pushing to non-default remotes

There's also the point noted that by default, github doesn't permit
this usage, and the contributor has to explicitly allow it - which
probably means the core dev need to know how to do it, and how to
explain that process to the contributor.

And probably others. I'm not interested in debating what constitutes
stuff that "everyone should know", or how "easy" or not git is. But
for someone coming from a familiarity with Mercurial (which means many
core devs) the learning curve is pretty steep (I'd consider that
self-evident, because of the differences between the 2 systems).

The decision to move to git/github has been made. It's not up for
debate whether core devs need to learn to deal with it. But we do need
to acknowledge that there's a significant learning curve, and while
core devs are contributing from their free time, learning the new
tooling is a major distraction from what they actually want to do,
which is work on Python code.

I don't have a good solution, but I do think we need to acknowledge
the issue and address it without making judgements on what other
people are familiar with or not.

Paul

PS There's a *lot* of stuff going by in the core-workflow list - the
new blurb and cherry-picker tools, lots of workflow recommendations,
etc. I haven't even looked at most of them yet, which means I'm
accumulating an increasing load of work I can do before I get back to
the point where I can contribute (and I'm familiar with git). Finding
the time to pay off that debt is getting harder and harder...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Sun, 25 Jun 2017 20:38:51 +0200
Stefan Krah  wrote:
> On Sun, Jun 25, 2017 at 10:02:44AM -0700, Nathaniel Smith wrote:
> > https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/
> > 
> > However, like Antoine, when I've tried to do this then all I've managed is
> > to get obscure errors from GitHub. Did I have the wrong incantations? Was
> > the permissions toggle set wrong? (I thought the web ui said it wasn't, but
> > maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
> > *this* work reliably or ergonomically?  
> 
> I don't know either.  Adding .patch to the PR URL, downloading the thing,
> editing as necessary and crediting the author in the commit message would
> be much much faster.

I might do that as well (actually did on another project after I
borked an attempt to push to the submitter's branch). Of course it
doesn't work if your aim is to collaborate with the submitter, only if
you want to take over and apply some polish before pushing.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

On 06/25/2017 11:01 AM, Nathaniel Smith wrote:
On Jun 25, 2017 10:27, "Larry Hastings" > wrote:



On 06/25/2017 10:02 AM, Nathaniel Smith wrote:

My dudes, in a previous life I helped invent distributed VCS, but
I still get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project
even started--and TeamWare had monotone beat by most of a decade. 
Not to downplay your achievements, but I don't think you "helped

invent DVCS".  Or did you work on Bitkeeper / TeamWare?


If your response to the previous message is to send an email to all of 
python-dev nitpicking credentials, then I think you missed the point...


Actually, I agreed with the point, I just wanted you to clarify about 
your claimed bona fides here.  And I notice your reply was sent "to all 
of python-dev" and contained a lot of "nitpicking"; either this behavior 
is permissible or it isn't.


DVCSes were a conceptual breakthrough, and the people behind it deserve 
all the praise and admiration we can heap on them.  If you "helped 
invent" them--that's fantastic!  Thank you!  If you didn't, then it's 
misleading to claim that you did, so please don't.



Perhaps I could have phrased it better; feel free to pretend I wrote a 
several paragraph history tracing which systems influenced which instead.


I don't think that's necessary.  "I was a core developer on a DVCS" 
would have handily made your point--you deeply understand DVCSes from 
both a conceptual and practical perspective--while also being brief and 
(IIUC) 100% accurate.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stefan Krah]

On Sun, Jun 25, 2017 at 10:02:44AM -0700, Nathaniel Smith wrote:
> https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/
> 
> However, like Antoine, when I've tried to do this then all I've managed is
> to get obscure errors from GitHub. Did I have the wrong incantations? Was
> the permissions toggle set wrong? (I thought the web ui said it wasn't, but
> maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
> *this* work reliably or ergonomically?

I don't know either.  Adding .patch to the PR URL, downloading the thing,
editing as necessary and crediting the author in the commit message would
be much much faster.



Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nathaniel Smith]

On Jun 25, 2017 10:27, "Larry Hastings"  wrote:



On 06/25/2017 10:02 AM, Nathaniel Smith wrote:

My dudes, in a previous life I helped invent distributed VCS, but I still
get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project even
started--and TeamWare had monotone beat by most of a decade.  Not to
downplay your achievements, but I don't think you "helped invent DVCS".  Or
did you work on Bitkeeper / TeamWare?


If your response to the previous message is to send an email to all of
python-dev nitpicking credentials, then I think you missed the point...

(There are many projects that attempted to somehow combine the terms
"distributed" and "VCS", but nowadays the overwhelmingly dominant use of
that term is to refer to system designs in the monotone/git/hg lineage.
Perhaps I could have phrased it better; feel free to pretend I wrote a
several paragraph history tracing which systems influenced which instead. I
don't think any of this affects the actual point, which is that you can be
arbitrarily familiar with how a software system works and still be lost and
confused on a regular basis, so people should pay attention and try to
avoid making comments that imply this indicates some personal deficit in
the asker.)

((Maybe I should clarify that the reason I'm being cranky about this isn't
really on my or Antoine's behalf, but on behalf of anyone lurking and
thinking "oh, python-dev says I suck, I guess I'm not cut out to be a
python contributor".))

(((Though also I *would* genuinely appreciate it if anyone could explain
how to make GitHub do the thing I couldn't figure out. Probably it's
something silly and obvious...)))

-n
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

> On Jun 25, 2017, at 1:02 PM, Nathaniel Smith  wrote:
> 
> However, like Antoine, when I've tried to do this then all I've managed is to 
> get obscure errors from GitHub. Did I have the wrong incantations? Was the 
> permissions toggle set wrong? (I thought the web ui said it wasn't, but maybe 
> I misunderstood.) It's a mystery. Has anyone figured out how to make *this* 
> work reliably or ergonomically?



I have used it. I don’t use it every day but I’ve never had it fail on me 
unless the contributor has unchecked the flag. I just ``git remote add  `` then checkout their branch, add more commits, and push 
to their branch.


—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

On 06/25/2017 10:02 AM, Nathaniel Smith wrote:
My dudes, in a previous life I helped invent distributed VCS, but I 
still get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project even 
started--and TeamWare had monotone beat by most of a decade. Not to 
downplay your achievements, but I don't think you "helped invent DVCS".  
Or did you work on Bitkeeper / TeamWare?



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

On 06/25/2017 01:33 AM, Antoine Pitrou wrote:

On Sat, 24 Jun 2017 21:37:46 -0700
Larry Hastings  wrote:

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? :-)


No, I'm not contradicting myself.  It's easy enough to do without blurb, 
but blurb makes it effortless.


For core developers who are adding NEWS entries all the time, it's 
little enough burden to ask them to install an extra tool.  There were 
enough constraints on the process that asking people to continually do 
it by hand seemed worse.


For non-core developers who may have never contributed to CPython 
before, and are doing this for probably the one time in their lives, 
having instructions on a web page telling them how to name and format a 
special file is probably better than simply requiring them to install a 
special tool.


Again, it's my hope that someone can make a static web page, to be 
checked in to the Dev Guide, that uses JS wizardry to create a 
downloadable file for you.  Also it might work to hide a simple 
"blurb-add.py" in the CPython library so that users of 3.7+ don't need 
an external tool in order to simply add a NEWS item.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nathaniel Smith]

On Jun 25, 2017 08:12, "Jakub Wilk"  wrote:

* Paul Sokolovsky , 2017-06-25, 11:47:

A GitHub PR is just a git branch (in somebody else's repository, but also
> in the repository it's submitted to). So, like any git branch, you can
> fetch it, re-branch to your local branch, apply any changes to it, rebase,
> push anywhere.
>

Right, this is documented here:
https://help.github.com/articles/checking-out-pull-requests-locally/


There're also various tools for dealing specifically with git branch layout
> as used by Github, and every real man writes their own
>

I have this in my gitconfig:

[alias]
hub-pr = ! "_g() { set -e -u; git fetch origin
\"pull/$1/head:gh-$1\" && git checkout \"gh-$1\"; }; _g"

If I want to checkout PR#42, I do:

$ git hub-pr 42


I believe you and Paul are missing the specific problem that Antoine was
talking about, which is: how can we easily make changes *to someone else's
PR*, i.e. these changes should show up in the diff view if you go to the
PR's web page. This requires not just getting a copy of the PR branch
locally, but also pushing it back to the original submitter's branch on
GitHub.

Allegedly this is possible in most cases (there's a permissions toggle the
submitter can set, but it's set by default):


https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/

However, like Antoine, when I've tried to do this then all I've managed is
to get obscure errors from GitHub. Did I have the wrong incantations? Was
the permissions toggle set wrong? (I thought the web ui said it wasn't, but
maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
*this* work reliably or ergonomically?

Also, as a general comment, not directed at Jakub: the posturing about how
easy git is reminds me of the posturing about how much better language X is
than others described here: http://blog.aurynn.com/contempt-culture-2. My
dudes, in a previous life I helped invent distributed VCS, but I still get
confused by fiddly git BS just like everyone else. I know you probably
aren't meaning to go around telling people that they're not Real
Programmers because they get confused like me, but you are and it's not
kind; please stop.

-n
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stefan Krah]

On Sun, Jun 25, 2017 at 05:52:49PM +0200, Antoine Pitrou wrote:
> On Mon, 26 Jun 2017 01:27:20 +1000
> Chris Angelico  wrote:
> > In the web programming bootcamp that I'm involved with, git is taught
> > in the very first week. It's not some arcane and hostile thing; the
> > command line is a fundamental tool that everyone is expected to become
> > friends with. The students learn about branching and merging
> > (including merge conflicts) and the pull-request workflow on the
> > second day of bootcamp.
> > 
> > Are we "real men" (and real women - we're not sexist here) because we
> > know how to type commands into a terminal?
> 
> The patronizing and not addressing the concrete issue at hand doesn't
> make your opinion about "real men and women" very interesting to me,
> sorry :-/

Indeed, perhaps all core devs should take a course at this "web programming
bootcamp" (whatever that is), so we finally know how to use the command line. ;)

Linus should also attend the "bootcamp", so he can learn git and the command
line:

   https://github.com/torvalds/linux/pull/17#issuecomment-5654674



Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Chris Angelico]

On Mon, Jun 26, 2017 at 1:52 AM, Antoine Pitrou  wrote:
> On Mon, 26 Jun 2017 01:27:20 +1000
> Chris Angelico  wrote:
>> On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
>> >> There're also various tools for dealing specifically with git branch
>> >> layout as used by Github, and every real man writes their own (because
>> >> it's easier to shoot a 5-liner than to review whether somebody else's
>> >> tool do what you need or not, it's all trivial git commands anyway).
>> >
>> > I guess I'm not a "real man" who likes to "shoot 5-liners" made of
>> > "trivial git commands" on my free time, then.  For some reason I'm not
>> > even interested in becoming one.  The part of computing where people
>> > posture as "real men" (or "wizards") by sequencing arcane commands on
>> > ill-conceived UIs has always felt uninteresting and hostile to me.
>>
>> In the web programming bootcamp that I'm involved with, git is taught
>> in the very first week. It's not some arcane and hostile thing; the
>> command line is a fundamental tool that everyone is expected to become
>> friends with. The students learn about branching and merging
>> (including merge conflicts) and the pull-request workflow on the
>> second day of bootcamp.
>>
>> Are we "real men" (and real women - we're not sexist here) because we
>> know how to type commands into a terminal?
>
> The patronizing and not addressing the concrete issue at hand doesn't
> make your opinion about "real men and women" very interesting to me,
> sorry :-/

My point is that EVERY developer needs to understand source control.
Since git is the dominant system these days, that basically means
everyone needs to understand git, although if you know (say) Mercurial
instead, that's adequate for 99% of situations (the other 1% being
where you're specifically collaborating on a git project). It's not
about some kind of supermen who know git, and everyone else who
doesn't. The command line is not an alternative to a GUI; it is
augmented by one. It is not "arcane" and "hostile"; it is a basic
fundamental of any sort of serious use of a computer.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Mon, 26 Jun 2017 01:27:20 +1000
Chris Angelico  wrote:
> On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
> >> There're also various tools for dealing specifically with git branch
> >> layout as used by Github, and every real man writes their own (because
> >> it's easier to shoot a 5-liner than to review whether somebody else's
> >> tool do what you need or not, it's all trivial git commands anyway).  
> >
> > I guess I'm not a "real man" who likes to "shoot 5-liners" made of
> > "trivial git commands" on my free time, then.  For some reason I'm not
> > even interested in becoming one.  The part of computing where people
> > posture as "real men" (or "wizards") by sequencing arcane commands on
> > ill-conceived UIs has always felt uninteresting and hostile to me.  
> 
> In the web programming bootcamp that I'm involved with, git is taught
> in the very first week. It's not some arcane and hostile thing; the
> command line is a fundamental tool that everyone is expected to become
> friends with. The students learn about branching and merging
> (including merge conflicts) and the pull-request workflow on the
> second day of bootcamp.
> 
> Are we "real men" (and real women - we're not sexist here) because we
> know how to type commands into a terminal?

The patronizing and not addressing the concrete issue at hand doesn't
make your opinion about "real men and women" very interesting to me,
sorry :-/

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Chris Angelico]

On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
>> There're also various tools for dealing specifically with git branch
>> layout as used by Github, and every real man writes their own (because
>> it's easier to shoot a 5-liner than to review whether somebody else's
>> tool do what you need or not, it's all trivial git commands anyway).
>
> I guess I'm not a "real man" who likes to "shoot 5-liners" made of
> "trivial git commands" on my free time, then.  For some reason I'm not
> even interested in becoming one.  The part of computing where people
> posture as "real men" (or "wizards") by sequencing arcane commands on
> ill-conceived UIs has always felt uninteresting and hostile to me.

In the web programming bootcamp that I'm involved with, git is taught
in the very first week. It's not some arcane and hostile thing; the
command line is a fundamental tool that everyone is expected to become
friends with. The students learn about branching and merging
(including merge conflicts) and the pull-request workflow on the
second day of bootcamp.

Are we "real men" (and real women - we're not sexist here) because we
know how to type commands into a terminal? If so, we're making sure
the next generation of programmers is exclusively real men and women.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jakub Wilk]

* Paul Sokolovsky , 2017-06-25, 11:47:
A GitHub PR is just a git branch (in somebody else's repository, but also in 
the repository it's submitted to). So, like any git branch, you can fetch it, 
re-branch to your local branch, apply any changes to it, rebase, push 
anywhere.


Right, this is documented here:
https://help.github.com/articles/checking-out-pull-requests-locally/

There're also various tools for dealing specifically with git branch layout as 
used by Github, and every real man writes their own


I have this in my gitconfig:

[alias]
hub-pr = ! "_g() { set -e -u; git fetch origin \"pull/$1/head:gh-$1\" && git checkout 
\"gh-$1\"; }; _g"

If I want to checkout PR#42, I do:

$ git hub-pr 42

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Sun, 25 Jun 2017 11:47:10 +0300
Paul Sokolovsky  wrote:
> > 
> > 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).  
> 
> Sorry, but how that can be true? A GitHub PR is just a git branch [...]

Well, git usage can still be a PITA, at least for a non-neligible
proportion of its users.  I remember trying to push some changes to
someone else's PR, only to find that GitHub considered the PR had an
empty diff to master.  I'm not sure what produced it, but I have other
things to do than deal with obnoxious tooling (be it git or GitHub) on
my volunteer time.

So, my current policy with PRs where pushing changes would be
required is just to look elsewhere in the hope that another core
developer comes and deals with it ;-)

> There're also various tools for dealing specifically with git branch
> layout as used by Github, and every real man writes their own (because
> it's easier to shoot a 5-liner than to review whether somebody else's
> tool do what you need or not, it's all trivial git commands anyway).

I guess I'm not a "real man" who likes to "shoot 5-liners" made of
"trivial git commands" on my free time, then.  For some reason I'm not
even interested in becoming one.  The part of computing where people
posture as "real men" (or "wizards") by sequencing arcane commands on
ill-conceived UIs has always felt uninteresting and hostile to me.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Sokolovsky]

Hello,

On Sun, 25 Jun 2017 10:33:20 +0200
Antoine Pitrou  wrote:

[]

> Hmm.  If it were so easy, you wouldn't have felt the need to add that
> functionality to blurb, right? :-)
> 
> 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).

Sorry, but how that can be true? A GitHub PR is just a git branch (in
somebody else's repository, but also in the repository it's submitted
to). So, like any git branch, you can fetch it, re-branch to your local
branch, apply any changes to it, rebase, push anywhere.

There're also various tools for dealing specifically with git branch
layout as used by Github, and every real man writes their own (because
it's easier to shoot a 5-liner than to review whether somebody else's
tool do what you need or not, it's all trivial git commands anyway).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Sat, 24 Jun 2017 21:37:46 -0700
Larry Hastings  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? :-)

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 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, or fix the occasional bit of reStructuredText
mis-syntax.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com