On Tue, 7 Feb 2017 at 11:17 Jim F.Hilliard wrote:

That's great, congratulations! I believe this change will make it way easier for people to get involved!

A small question, since people can now submit new issues via pulls instead of going to bugs.python.org, what will be the purpose of the latter?

The issue tracker is not moving. GitHub will be used for code hosting and pull request management. Tracking bugs and such will stay at bugs.python.org. There's now integration between GitHub and bpo so that if you reference an issue in a pull request a connection will be made on bpo. -Brett

As I skimmed through cpython-devguide.readthedocs.io I've see the issue tracker being referenced in certain areas (File a bug section, Reviewing) so I'm not sure I understand how they overlap.

_______________________________________________ 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

On Tue, Feb 7, 2017 at 11:38 PM, Victor Stinner wrote:

I know that different people have different expectation on GitHub. I would like to take the opportunity of migrating to Git to use the "author" and "committer" fields. If the author is set to the real author, the one who proposed the change on the bug tracker or someone else, we will be able to compute statistics on most active contributors to more easily detect them and promote them to core developers.

What do you think?

I am +1 to this idea. The intention behind this idea is also good one. * When the patches come from Github PRs, the contribution authors are automatically tracked. The comitter would be merging the changes from the authors. * When contribution comes via Patches/ or for many existing patches, setting the author is a good idea. I have one question. If we disallow direct push to branches and the core-dev has to create a PR to merge the changes in, I guess it is still possible to have author information in the commit.

On Tue, 7 Feb 2017 at 23:38 Victor Stinner wrote:

2017-02-08 8:35 GMT+01:00 Victor Stinner :

...

I'm sure the patch author would appreciate it, but I don't think we need to require it as we have gone this long without it.

I know that different people have different expectation on GitHub. I would like to take the opportunity of migrating to Git to use the "author" and "committer" fields. If the author is set to the real author, the one who proposed the change on the bug tracker or someone else, we will be able to compute statistics on most active contributors to more easily detect them and promote them to core developers.

What do you think?

Personally I think this would be great for everyone to do. Do you want to propose a PR for the devguide to document what to include (I assume committer will automatically be filled with the core dev's info so that should only require authorship to be specified).

I agree that pull requests avoid the issues of filling manually the author field, but I expect that not everyone will use PR, especially because we will still use our current bug tracker which accepts to attach patch files. Ok to propose them to create a PR instead.

My expectation is there will be a transition period of dealing with patches on bpo which have submitters who don't want to bother making an equivalent PR on GitHub.

On Wed, 8 Feb 2017 at 12:33 Terry Reedy wrote:

On 2/8/2017 2:38 AM, Victor Stinner wrote:

...

I know that different people have different expectation on GitHub. I would like to take the opportunity of migrating to Git to use the "author" and "committer" fields. If the author is set to the real author, the one who proposed the change on the bug tracker or someone else, we will be able to compute statistics on most active contributors to more easily detect them and promote them to core developers.

What do you think?

Many patches have multiple authors. Does the 'author' field allow that?

No.

Often, the committer adds missing chunks or rewrites the work with various degrees of editing. Sometimes a read a patch for the idea and then start fresh with the actual code. An acknowledgement in the news entry can be written different ways to reflect the situation.

Yep, I assume the Misc/NEWS entry, commit log, and Misc/ACKS all provide opportunities to overcome the shortcoming of a single author attribution. -Brett

-- Terry Jan Reedy

_______________________________________________ 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

On Wed, 8 Feb 2017 at 13:33 Victor Stinner wrote:

2017-02-08 21:32 GMT+01:00 Terry Reedy :

...

Many patches have multiple authors. Does the 'author' field allow that? Often, the committer adds missing chunks or rewrites the work with various degrees of editing. Sometimes a read a patch for the idea and then start fresh with the actual code. An acknowledgement in the news entry can be written different ways to reflect the situation.

In my experience, the common case is two "authors": the initial patch autor, and the core dev who makes minor changes like filling Misc/NEWS and adjust some parts of the code. If changes are minor, there is no need to elaborate. But if changes are non straightforward, they can be listed in the commit messages.

If a patch has more author, you have to pick the name, decide which author helped the most, and add the other authors in the commit message.

Using GitHub, it will become easier to use patch series, and so smaller changes. Each change may have a different author :-D

Don't forget we are doing squash merges, so if a PR has multiple authors then the author information won't carry forward in git (I don't know if GitHub has custom logic to work around this).

On 09.02.2017 00:03, Victor Stinner wrote:

2017-02-08 23:42 GMT+01:00 Brett Cannon :

...

Don't forget we are doing squash merges, Ah, I didn't know. Why not using merges?

Same question here. I see no benefit just overhead, mistakes and longer processes. Sven

Brett Cannon wrote:

Because other core devs wanted a linear history. This preference was very strong to the point people were willing to forgo the Merge button in GitHub's web UI to enforce it until GitHub added the squash merge support for the Merge button.

Actually, there's a third option - using *rebase and merge* [1] button. It does not produce a merge commit but preserves commits from the pull request. [1] https://help.github.com/articles/about-pull-request-merges/#rebase-and-merge... On Thu, Feb 9, 2017 at 1:53 AM, Brett Cannon wrote:

On Wed, 8 Feb 2017 at 15:04 Victor Stinner wrote:

...

2017-02-08 23:42 GMT+01:00 Brett Cannon :

...

Don't forget we are doing squash merges,

Ah, I didn't know. Why not using merges?

Because other core devs wanted a linear history. This preference was very strong to the point people were willing to forgo the Merge button in GitHub's web UI to enforce it until GitHub added the squash merge support for the Merge button. This was decided over a year ago and documented in PEP 512 as the decision made since I believe the beginning of that PEP.

Now I know Victor was asking out of curiosity, but I'm going to ask nicely now and then ignore later anyone who starts second-guessing my decisions at this point as someone did as a follow-up to Victor's question. This process has been discussed for over 2 years and PEP 512 has existed for over one year. There has also been an open mailing list where I have held discussions on various topics and people have been free to ask and participate on. Now is not the time to start second-guessing things that have already been decided and discussed to great length before we even have any experience with the chosen workflow.

The final stretch of this whole process has been going smoothly, so I'm trying to ask nicely that everyone give me the benefit of the doubt and assume everything has been thought out and there is a reason behind everything before you choose to second-guess my decisions at the 11th hour.

_______________________________________________ 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/ihor%40kalnytskyi.com