Re: [core-workflow] Help needed: best way to convert hg repos to git?
On 02/11/2016 07:07 PM, Brett Cannon wrote: > On Thu, Feb 11, 2016, 16:43 Nicolás Alvarez wrote: >> It depends on how crazy you want to go. For example, SVN-era merges >> don't appear as merges, but looks like some SVN-era branches don't >> exist in Hg to begin with (Would I need to get cpython-fullhistory? >> Cloning it gives me a 400 Bad Request). Do we care about that? > If you are not an even clone it then that shows how much > people who are. Um, could you repeat that? In English? :) -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Some questions
On 05/08/2016 05:43 PM, Senthil Kumaran wrote: On Sun, May 8, 2016 at 4:40 PM, Émanuel Barry wrote: Take each X commit (say, every 100^th or 1000^th commit, or even every commit if we decide to be insane^Wprecise), store hashes of all files at that revision with possibly the file tree, in a .py file as a list or dict, or json or anything you prefer. Then I upload it for you to look at and you can compare with the mercurial repo. Or we run the same script on the mercurial repo and compare the resulting files. If we store anything externally, that could start limiting us. I read that as generating a temp file from each tool (git and hg) and then comparing them -- not as storing those files. (I could be wrong, though.) -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] self-approving pull requests
On 02/22/2017 08:39 AM, Donald Stufft wrote: On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: Since we're squashing commits wouldn't that obliterate the original author's credit for the work? Yes, github will credit the person who opened the PR, but the person who made the person who made the PR can check the box (which I *believe* is checked by default) to allow maintainers to edit their PR. If that is checked, then maintainers can edit their branch on their fork directly, in which case no credit gets lost. So just make your changes directly in their branch, and things will continue to work. Is there a list of instructions somewhere on how to do all that? -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] git notifications
One thing that seems to be lacking: names of commenters. In the recent thread about [Provide guidance on editing PRs prior to merge (#129)] there are several entries, from at least two people, and I have no idea who they are or exactly which one said what because their names are not showing up anywhere that I can see. Granted I could go and look on GitHub directly, but this feels like a regression from our previous work flow. -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] git notifications
The issue link: https://github.com/python/devguide/issues/129 -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] git notifications
On 02/22/2017 01:32 PM, Senthil Kumaran wrote: On Wed, Feb 22, 2017 at 12:46 PM, Ethan Furman wrote: The issue link: https://github.com/python/devguide/issues/129 Well, at least I could not understand the original problem properly. Here is my screenshot of the discuss as it appears in my email https://www.dropbox.com/s/gdl5ke0ffzirt85/Screenshot%202017-02-22%2012.50.44.png?dl=0 And I see the authors name in the discussion, their FROM email id's are masked by github. Interesting. This is what I see in Thunderbird: https://www.dropbox.com/s/b6lgtyyn4yspnu4/git-no_names_with_notifications.png?dl=0 -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] git notifications
Huh. I created a new profile as I was having other issues with Thunderbird, and now I see the names on the git notifications. May have been an address book issue. Problem solved, thanks for the help everyone. -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Use something other than an In-joke for Trigger Phrases
On 10/08/2017 09:44 AM, Brett Cannon wrote: I actually wouldn't want the bot name in the trigger phrase since you're not addressing the bot but the reviewer(s). So using something that is unambiguous as a trigger phrase like "please re-review" or "please review again" that won't come up in conversation about what is required should be enough to be unambiguous of the intent of the commenter as well has not seeming quite so forced. You're addressing the bot to notify the reviewers. It's like asking one's secretary to schedule an appointment with one's peers. -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Use something other than an In-joke for Trigger Phrases
On 10/10/2017 11:51 AM, Brett Cannon wrote: I just merged the PR and went with "I have made the requested changes; please review again". Figured this makes people aware that they are to have addressed the changes before requesting a review and has them saying "please". :) Plus there's no way anyone will accidentally type that in conversation on a pull request. Unless they have it attached to a macro and accidentally activate it. ;) -- ~Ethan~ ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] adding a news entry via the web interface
Howdy! So I have an issue [1] that looks good but is missing the news entry. Is there any way to add that directly via the web interface? -- ~Ethan~ [1] https://github.com/python/cpython/pull/4288 ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] Re: adding a news entry via the web interface
On 03/26/2018 10:24 AM, Mariatta Wijaya wrote: Not yet, I was thinking of implementing it, as I wanted this feature too. But wasn't sure if others will also find it useful, so I haven't put a lot of effort into it. My idea is a web interface where we can supply the GitHub PR number, bpo number, and the desired news entry, and have that magically added to the PR via a button click. The web ui should allow any core devs to add the news entry to any PRs. Other contributors should only be able to add to their own PR. And MISC/Acks as well. Maybe WHATSNEW? Just in case you were bored. ;) -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] confusing result from `make patchcheck`
Running `make patchcheck` resulted in the following: Getting the list of files that have been added/changed ... fatal: ambiguous argument 'origin/3.7': unknown revision or path not in the working tree. How does one fix that? The commands leading up to this: git checkout -b bpo-33217-3.7 upstream/3.7 make distclean cp Modules/Setup.dist Modules/Setup ./configure --with-pydebug && make -j2 ./python -m test.regrtest test_enum.py ./python -m test.regrtest make patcheck Any help appreciated! :) -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] Re: confusing result from `make patchcheck`
On 04/05/2018 08:07 AM, Oleg Broytman wrote: On Thu, Apr 05, 2018 at 07:31:02AM -0700, Ethan Furman wrote: Getting the list of files that have been added/changed ... fatal: ambiguous argument 'origin/3.7': unknown revision or path not in the working tree. How does one fix that? git fetch origin 3.7:3.7 Resulted in: ethan@code:~/source/git-python/cpython$ git fetch 3.7:3.7 ssh: connect to host 3.7 port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] Re: confusing result from `make patchcheck`
On 04/05/2018 09:21 AM, Oleg Broytman wrote: On Thu, Apr 05, 2018 at 09:11:14AM -0700, Ethan Furman wrote: On 04/05/2018 08:07 AM, Oleg Broytman wrote: On Thu, Apr 05, 2018 at 07:31:02AM -0700, Ethan Furman wrote: Getting the list of files that have been added/changed ... fatal: ambiguous argument 'origin/3.7': unknown revision or path not in the working tree. How does one fix that? git fetch origin 3.7:3.7 Resulted in: ethan@code:~/source/git-python/cpython$ git fetch 3.7:3.7 ^ origin git fetch origin 3.7:3.7 ^^ Ah, oops. Okay, tried again, still seeing problem. ethan@code:~/source/git-python/cpython$ git fetch origin 3.7:3.7 fatal: Couldn't find remote ref 3.7 ethan@code:~/source/git-python/cpython$ git fetch upstream 3.7:3.7 From github.com:python/cpython * [new branch] 3.7-> 3.7 ethan@code:~/source/git-python/cpython$ git branch 3.7 bpo-29237 * bpo-33217-3.7 enum_ignore master ethan@code:~/source/git-python/cpython$ make patchcheck running build running build_ext Python build finished successfully! The necessary bits to build these optional modules were not found: _dbm _gdbm _ssl _uuid To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Could not build the ssl module! Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host(). LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381 running build_scripts copying and adjusting /home/ethan/source/git-python/cpython/Tools/scripts/pydoc3 -> build/scripts-3.7 copying and adjusting /home/ethan/source/git-python/cpython/Tools/scripts/idle3 -> build/scripts-3.7 copying and adjusting /home/ethan/source/git-python/cpython/Tools/scripts/2to3 -> build/scripts-3.7 copying and adjusting /home/ethan/source/git-python/cpython/Tools/scripts/pyvenv -> build/scripts-3.7 changing mode of build/scripts-3.7/pydoc3 from 664 to 775 changing mode of build/scripts-3.7/idle3 from 664 to 775 changing mode of build/scripts-3.7/2to3 from 664 to 775 changing mode of build/scripts-3.7/pyvenv from 664 to 775 renaming build/scripts-3.7/pydoc3 to build/scripts-3.7/pydoc3.7 renaming build/scripts-3.7/idle3 to build/scripts-3.7/idle3.7 renaming build/scripts-3.7/2to3 to build/scripts-3.7/2to3-3.7 renaming build/scripts-3.7/pyvenv to build/scripts-3.7/pyvenv-3.7 ./python ./Tools/scripts/patchcheck.py Getting base branch for PR ... origin/3.7 Getting the list of files that have been added/changed ... fatal: ambiguous argument 'origin/3.7': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' 0 files Fixing Python file whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS.d updated with `blurb` ... NO configure regenerated ... not needed pyconfig.h.in regenerated ... not needed -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] DO-NOT-MERGE-UNTIL-3.9
Can we get the above tag added? -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] Re: DO-NOT-MERGE-UNTIL-3.9
On 09/15/2018 09:08 AM, Brett Cannon wrote: Thinking to the future, eh? 😉 :-) While I don't have a fundamental objection, what does this get you that an issue doesn't? Since the code will be sitting in your fork for that length it wont be lost. Is it to make it easier to keep it synced and tested for the next year? Mostly to make it easier for me not to forget to do it. ;) I suppose a separate issue with that text in the title would also work. -- ~Ethan~ ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
