GitHub migration scheduled for Friday
To let the non-core devs know, the GitHub migration will be happening this Friday. For those of you who use the current GitHub mirror to create patches, do be aware that the hashes will most likely be changing so don't expect your checkout to work past Thursday (you can always generate a patch and apply it to a fresh checkout). Otherwise https://cpython-devguide.readthedocs.io/en/github/ is what the devguide will become on Friday if you want to read now instead of waiting for the official switch-over (although for non-core devs the migration basically means you can use GitHub to submit changes instead of uploading patches).
2017-02-07 10:03 GMT-08:00 Brett Cannon <brett@python.org>:
To let the non-core devs know, the GitHub migration will be happening this Friday. For those of you who use the current GitHub mirror to create patches, do be aware that the hashes will most likely be changing so don't expect your checkout to work past Thursday (you can always generate a patch and apply it to a fresh checkout). Otherwise https://cpython- devguide.readthedocs.io/en/github/ is what the devguide will become on Friday if you want to read now instead of waiting for the official switch-over (although for non-core devs the migration basically means you can use GitHub to submit changes instead of uploading patches).
This is great, I'm looking forward to being able to submit pull requests to CPython. Thanks Brett and others for all your hard work on this!
_______________________________________________ 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/ jelle.zijlstra%40gmail.com
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? 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.
On Tue, 7 Feb 2017 at 11:17 Jim F.Hilliard <d.f.hilliard@gmail.com> 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
Nice, good news. On 02/07, Brett Cannon wrote:
To let the non-core devs know, the GitHub migration will be happening this Friday. For those of you who use the current GitHub mirror to create patches, do be aware that the hashes will most likely be changing so don't expect your checkout to work past Thursday (you can always generate a patch and apply it to a fresh checkout). Otherwise https://cpython-devguide.readthedocs.io/en/github/ is what the devguide will become on Friday if you want to read now instead of waiting for the official switch-over (although for non-core devs the migration basically means you can use GitHub to submit changes instead of uploading patches).
_______________________________________________ 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/stephane%40wirtel.be
-- Stéphane Wirtel - http://wirtel.be - @matrixise
(Oops, I wrote privately to Brett, so he replied me in private. So here is a copy of our emails.) Brett Cannon via gmail.com On Tue, 7 Feb 2017 at 13:42 Victor Stinner <victor.stinner@gmail.com> wrote:
If I push a patch file written by someone else, should I try to use the author full name + email?
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.
Currently, it requires some tricks to get these informations (the email is partially hidden in the big tracker user list). Or are we moving slowly to GitHub pull requests only?
I hope we're moving quickly and not slowly. :)
Maybe the simplest option is to ask these informations to the author :-)
I suspect if the patch author is still active you could ask them to make their patch into a PR and that will solve this problem. -Brett
2017-02-08 8:35 GMT+01:00 Victor Stinner <victor.stinner@gmail.com>:
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? I agree that pull requests avoid the issues of filling manually the author field, but I expect that no 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. Victor
On Tue, Feb 7, 2017 at 11:38 PM, Victor Stinner <victor.stinner@gmail.com> 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 Wed, Feb 8, 2017 at 8:52 AM, Senthil Kumaran <senthil@uthcode.com> wrote:
On Tue, Feb 7, 2017 at 11:38 PM, Victor Stinner <victor.stinner@gmail.com> 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.
If we enable auto-PR creation, which was done by Anish as part of his GSoC we might be able to set the original author based on the github username associated with his user on bpo. But I'm guessing we need more work in this area ;)
On Tue, 7 Feb 2017 at 23:38 Victor Stinner <victor.stinner@gmail.com> wrote:
2017-02-08 8:35 GMT+01:00 Victor Stinner <victor.stinner@gmail.com>:
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 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? 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. -- Terry Jan Reedy
On Wed, 8 Feb 2017 at 12:33 Terry Reedy <tjreedy@udel.edu> 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
2017-02-08 21:32 GMT+01:00 Terry Reedy <tjreedy@udel.edu>:
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 Victor
On Wed, 8 Feb 2017 at 13:33 Victor Stinner <victor.stinner@gmail.com> wrote:
2017-02-08 21:32 GMT+01:00 Terry Reedy <tjreedy@udel.edu>:
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 Wed, 8 Feb 2017 at 15:04 Victor Stinner <victor.stinner@gmail.com> wrote:
2017-02-08 23:42 GMT+01:00 Brett Cannon <brett@python.org>:
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.
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 <brett@python.org> wrote:
On Wed, 8 Feb 2017 at 15:04 Victor Stinner <victor.stinner@gmail.com> wrote:
2017-02-08 23:42 GMT+01:00 Brett Cannon <brett@python.org>:
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
participants (10)
-
Brett Cannon -
Ihor Kalnytskyi -
Jelle Zijlstra -
Jim F.Hilliard -
Maciej Szulik -
Senthil Kumaran -
Stephane Wirtel -
Sven R. Kunze -
Terry Reedy -
Victor Stinner