On Thu, 5 Apr 2018 at 02:49 Skip Montanaro wrote:

...

There are a bunch of open issues regarding gdb support including one with a PR in need of review for 3.6+.

I rejected one (which assumed everyone now uses a python-aware gdb), commented on another (ceval.c-related name changes in several commands), and created a PR for third (documentation for the user-defined commands). Unfortunately, it's been so long since I contributed, I don't quite understand the ins and outs of the workflow anymore. In particular, I could find no way to add the "skip news" label.

There's a "Labels" section in the right-hand column. You can click "Labels" and a drop-down of available and selected labels will show up. -Brett

I'm afraid someone might have to intervene here:

https://github.com/python/cpython/pull/6384

Skip _______________________________________________ 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

Modifying GitHub Labels is only available to people with commit privs and, IIRC, Skip asked to drop his commit privs a few years ago (although I'm sure we would all be happy to welcome him back!).

Alas, then I would feel some obligation to be semi-responsive to buggy things in areas where I have some interest. I'd really rather be out on my bike. :-) S

On Apr 5, 2018, at 14:48, Terry Reedy wrote:

On 4/5/2018 5:47 AM, Skip Montanaro wrote:

...

...

There are a bunch of open issues regarding gdb support including one with a PR in need of review for 3.6+. I rejected one (which assumed everyone now uses a python-aware gdb), commented on another (ceval.c-related name changes in several commands), and created a PR for third (documentation for the user-defined commands). Unfortunately, it's been so long since I contributed, I don't quite understand the ins and outs of the workflow anymore. In particular, I could find no way to add the "skip news" label. I'm afraid someone might have to intervene here: https://github.com/python/cpython/pull/6384

You created the PR from your local python repository master branch. I have done this, with negative consequences. I believe you will find life with git easier if you never edit your master branch, or at least, never make local commits to it, and only commit to and create PRs from special-purpose patch branches, as described in the devguide.

That's a good observation, Terry. The main problem is that, when a core developer merges the PR from your local repo to the main python/cpython repo, we do a squash merge which means that the change or changes committed in the python/cpython and included in the PR will end up with a single new hash id that differs from what you originally committed in your cpython fork. So the next time you pull to your cpython fork (conventionally "origin") from the main cpython repo ("upstream"), there will be a conflict on the "normal" branch, i.e. master, 3.7, etc, requiring a merge or rebase, but you don't want to do that since the change is already upstream. Once the PR is merged into the main cpython repo, you can fix the problem by force removing the original commit(s) from the "normal" branch in your forked repo. See for example: https://stackoverflow.com/questions/9646167/clean-up-a-fork-and-restart-it-f... -- Ned Deily nad@python.org -- []