Re: [core-workflow] Help needed: adding GitHub usernames to bugs.python.org
On 7 February 2016 at 05:22, Brett Cannon wrote: > IOW if people want to help in a way that involves coding, then please help > Ezio with b.p.o stuff. This is also beneficial long-term for maintaining the > issue tracker and changes that will be needed in the future for getting > cpython moved over. > > As for a PSF account on dockerhub, I would ask the PSF infra team what they > think and have them administer it. A PSF account on DockerHub sounds like a good idea to me - that would likely also be useful for hosting the reference image for the manylinux1 build environment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Help needed: best way to convert hg repos to git?
On 7 February 2016 at 05:42, Brett Cannon wrote: > FIrst off, thanks to everyone who has stepped out and started running > various approaches to test them out! Any and all help is appreciated since > there are a lot of parts to this transition and I definitely don't want to > do it on my own (especially since Python 2.7 would have its last release by > the time I would finish with all the work). > > Second, does anyone -- or group of people -- want to own this and figure out > what to try out, keep track of what has been tried, come up with some way to > evaluate the results (both for accuracy in the conversion but also if there > is some way to say one is better than another), and come back to the list > with a solution? All I ask is you try to do it in the open (whether it's by > a Google Doc that's open to the public for comment or a GitHub repo, I don't > care) so people who want to help can? It seems there are people definitely > willing to try out the tools and report back, but I'm looking for > someone/people to organize the effort and come back to me with a thought-out > solution so I don't have to. :) For beaker-project.org, I found it really useful to have an "administrivia" repo in our Gerrit instance for all the random scripts that didn't have a proper home, but we also didn't want the sole copy living on someone's hard drive. Creating a similar repo (e.g. "core-workflow") under https://github.com/python would likely be useful here, since it would not only give people a place to collaborate on utility scripts, but also an ad hoc issue tracker for tasks that don't have a more appropriate home. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Presentation on Rust's GitHub based automation tools
I was at linux.conf.au 2016 last week, and one of the presentations was from Mozilla's Emily Dunham on some of the infrastructure automation they use with Rust and other GitHub based projects: https://www.youtube.com/watch?v=dIageYT0Vgg In addition to their merge bot project homu (which we've talked about previously), they also have: highfive (a greeter bot): https://github.com/nrc/highfive starters (an issue curator): https://starters.servo.org/ The first project looks for folks submitting their first PR or issue, and responds with some standard info to save humans from having to do it later (like pointers to the Code of Conduct and the Contributor Licensing Agreement, as well as explanations of how the contribution process works) The second one is designed to provide a better answer to the "How do I get started?" question by making it easy for developers to tag simpler issues. This could presumably also be used to provide separate views based on what folks want to work on (e.g. documentation, Python code, C code) While these wouldn't necessarily be something we wanted to set up immediately, it likely makes a lot of sense to try to share the tool maintenance load with Mozilla rather than going for a completely custom setup. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Help needed: best way to convert hg repos to git?
FIrst off, thanks to everyone who has stepped out and started running various approaches to test them out! Any and all help is appreciated since there are a lot of parts to this transition and I definitely don't want to do it on my own (especially since Python 2.7 would have its last release by the time I would finish with all the work). Second, does anyone -- or group of people -- want to own this and figure out what to try out, keep track of what has been tried, come up with some way to evaluate the results (both for accuracy in the conversion but also if there is some way to say one is better than another), and come back to the list with a solution? All I ask is you try to do it in the open (whether it's by a Google Doc that's open to the public for comment or a GitHub repo, I don't care) so people who want to help can? It seems there are people definitely willing to try out the tools and report back, but I'm looking for someone/people to organize the effort and come back to me with a thought-out solution so I don't have to. :) On Sat, 6 Feb 2016 at 09:16 Oleg Broytman wrote: > On Sat, Feb 06, 2016 at 05:57:47PM +0100, Petr Viktorin > wrote: > > On 02/06/2016 05:48 PM, Oleg Broytman wrote: > > > $ git remote add gh g...@github.com:phdru/cpython.git > > > > > > $ git push --all gh > > > > > >See the result at https://github.com/phdru/cpython > > > > You might also want to try something like > > > >$ git repack -a -d -f --depth=250 --window=250 > > > > after importing to decrease the size of the repository for everyone > > pulling from you. > > > > (Reference: https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html) > >See the discussion of this old and outdated message at PEP 103: > https://www.python.org/dev/peps/pep-0103/#database-maintenance > >The recommended parameters for git repack are --depth=20 --window=250 > See http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html > >But yes, you're right, git gc/repack is very much recommended. > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name >Programmers don't die, they just GOSUB without RETURN. > ___ > 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 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] Help needed: adding GitHub usernames to bugs.python.org
On Sat, 6 Feb 2016 at 10:25 Ezio Melotti wrote: > On Sat, Feb 6, 2016 at 4:01 AM, Brett Cannon wrote: > > > https://www.python.org/dev/peps/pep-0512/#adding-github-username-support-to-bugs-python-org > > > > In order for the CLA bot to work, I need people to be able to add their > > GitHub usernames to their bugs.python.org profile. I also need some > API(s) > > that I can hit from the bot that lets me pass in a GitHub username -- or > > names, since there can be more than one, but I'm also fine making > multiple > > individual requests instead of multiple names in a single request -- and > get > > back some kind of signed/not signed/no GitHub username response (can > even be > > GitHub username -> b.p.o username in one call and then b.p.o CLA status > as > > another if that's easier). > > > > I'm not sure if Ezio was planning to own this or not, so I'm asking if > > anyone wants to take this on or help Ezio with the work if he does want > to > > lead it (or R. David if he wants to lead it). > > Adding this should be relatively easy -- the new field must be added > to the schema and a few extra lines in the templates should be added > as well to allow users to add/edit/see it. Testing it is a bit more > difficult though. > For the API, we can add a temporary page to retrieve the git user name > as json or wait until I finish reviewing and merging the REST API > patch (any help on this is more than welcome). > I'm trying to set up a docker container with a test instance of the > tracker and create a few test issues/users, so that I can test things > more conveniently. It might also be useful to make a psf account on > dockerhub (or somewhere else) where to keep this and possibly other > containers. > IOW if people want to help in a way that involves coding, then please help Ezio with b.p.o stuff. This is also beneficial long-term for maintaining the issue tracker and changes that will be needed in the future for getting cpython moved over. As for a PSF account on dockerhub, I would ask the PSF infra team what they think and have them administer it. ___ 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] Help needed: adding GitHub usernames to bugs.python.org
On Sat, Feb 6, 2016 at 4:01 AM, Brett Cannon wrote: > https://www.python.org/dev/peps/pep-0512/#adding-github-username-support-to-bugs-python-org > > In order for the CLA bot to work, I need people to be able to add their > GitHub usernames to their bugs.python.org profile. I also need some API(s) > that I can hit from the bot that lets me pass in a GitHub username -- or > names, since there can be more than one, but I'm also fine making multiple > individual requests instead of multiple names in a single request -- and get > back some kind of signed/not signed/no GitHub username response (can even be > GitHub username -> b.p.o username in one call and then b.p.o CLA status as > another if that's easier). > > I'm not sure if Ezio was planning to own this or not, so I'm asking if > anyone wants to take this on or help Ezio with the work if he does want to > lead it (or R. David if he wants to lead it). Adding this should be relatively easy -- the new field must be added to the schema and a few extra lines in the templates should be added as well to allow users to add/edit/see it. Testing it is a bit more difficult though. For the API, we can add a temporary page to retrieve the git user name as json or wait until I finish reviewing and merging the REST API patch (any help on this is more than welcome). I'm trying to set up a docker container with a test instance of the tracker and create a few test issues/users, so that I can test things more conveniently. It might also be useful to make a psf account on dockerhub (or somewhere else) where to keep this and possibly other containers. Best Regards, Ezio Melotti ___ 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] Help needed: best way to convert hg repos to git?
On Sat, Feb 06, 2016 at 05:57:47PM +0100, Petr Viktorin wrote: > On 02/06/2016 05:48 PM, Oleg Broytman wrote: > > $ git remote add gh g...@github.com:phdru/cpython.git > > > > $ git push --all gh > > > >See the result at https://github.com/phdru/cpython > > You might also want to try something like > >$ git repack -a -d -f --depth=250 --window=250 > > after importing to decrease the size of the repository for everyone > pulling from you. > > (Reference: https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html) See the discussion of this old and outdated message at PEP 103: https://www.python.org/dev/peps/pep-0103/#database-maintenance The recommended parameters for git repack are --depth=20 --window=250 See http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html But yes, you're right, git gc/repack is very much recommended. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Help needed: best way to convert hg repos to git?
On 02/06/2016 05:48 PM, Oleg Broytman wrote: > On Sat, Feb 06, 2016 at 04:50:51PM +0100, Oleg Broytman > wrote: >> Hello! >> >> On Sat, Feb 06, 2016 at 01:57:15AM +, Brett Cannon >> wrote: >>> https://www.python.org/dev/peps/pep-0512/#define-commands-to-move-a-mercurial-repository-to-git >>> >>> There appear to be multiple ways to convert hg repos to git, but no clear >>> winner. It would be great if some one/people took on the task of evaluating >>> the tools available out there by converting the cpython repo and seeing >>> which one has the best results. >> >>Let's me try git-remote-hg transport. >> >> $ hg clone https://hg.python.org/cpython/ cpython-hg >> >> $ time git clone hg::cpython-hg cpython-git >> real 39m44.600s >> user 45m54.192s >> sys 1m4.184s >> >> $ cd cpython-git/ > > $ git remote add gh g...@github.com:phdru/cpython.git > > $ git push --all gh > >See the result at https://github.com/phdru/cpython You might also want to try something like $ git repack -a -d -f --depth=250 --window=250 after importing to decrease the size of the repository for everyone pulling from you. (Reference: https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html) ___ 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] Help needed: best way to convert hg repos to git?
On Sat, Feb 06, 2016 at 04:50:51PM +0100, Oleg Broytman wrote: > Hello! > > On Sat, Feb 06, 2016 at 01:57:15AM +, Brett Cannon > wrote: > > https://www.python.org/dev/peps/pep-0512/#define-commands-to-move-a-mercurial-repository-to-git > > > > There appear to be multiple ways to convert hg repos to git, but no clear > > winner. It would be great if some one/people took on the task of evaluating > > the tools available out there by converting the cpython repo and seeing > > which one has the best results. > >Let's me try git-remote-hg transport. > > $ hg clone https://hg.python.org/cpython/ cpython-hg > > $ time git clone hg::cpython-hg cpython-git > real 39m44.600s > user 45m54.192s > sys 1m4.184s > > $ cd cpython-git/ $ git remote add gh g...@github.com:phdru/cpython.git $ git push --all gh See the result at https://github.com/phdru/cpython PS. I am `phdru' at Github. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Help needed: best way to convert hg repos to git?
I'll try hg-git! On February 5, 2016 7:57:15 PM CST, Brett Cannon wrote: >https://www.python.org/dev/peps/pep-0512/#define-commands-to-move-a-mercurial-repository-to-git > >There appear to be multiple ways to convert hg repos to git, but no >clear >winner. It would be great if some one/people took on the task of >evaluating >the tools available out there by converting the cpython repo and seeing >which one has the best results. > > > > >___ >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 -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___ 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] Help needed: best way to convert hg repos to git?
Hello! On Sat, Feb 06, 2016 at 01:57:15AM +, Brett Cannon wrote: > https://www.python.org/dev/peps/pep-0512/#define-commands-to-move-a-mercurial-repository-to-git > > There appear to be multiple ways to convert hg repos to git, but no clear > winner. It would be great if some one/people took on the task of evaluating > the tools available out there by converting the cpython repo and seeing > which one has the best results. Let's me try git-remote-hg transport. $ hg clone https://hg.python.org/cpython/ cpython-hg $ time git clone hg::cpython-hg cpython-git real 39m44.600s user 45m54.192s sys 1m4.184s $ cd cpython-git/ * master 6bd585f merge from 3.5 remotes/origin/HEAD -> origin/master remotes/origin/branches/2.7 9842886 Fix userinfo example presented in urllib2 howto. remotes/origin/branches/3.2 51e4a9f Issue #25940: On Windows, connecting to port 444 returns ETIMEDOUT remotes/origin/branches/3.3 a017765 Issue #25940: Merge ETIMEDOUT fix from 3.2 into 3.3 remotes/origin/branches/3.4 1b9c53a reject negative data_size remotes/origin/branches/3.5 411a8a5 Fix userinfo example presented in urllib2 howto. remotes/origin/branches/default 6bd585f merge from 3.5 remotes/origin/master 6bd585f merge from 3.5 $ git log --decorate --graph -5 * commit 6bd585f (HEAD, origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master, master) |\ Merge: 10cbbbf 411a8a5 | | Author: Senthil Kumaran | | Date: Fri Feb 5 19:37:47 2016 -0800 | | | | merge from 3.5 | | | * commit 411a8a5 (origin/branches/3.5, refs/hg/origin/branches/3.5) | | Author: Senthil Kumaran | | Date: Fri Feb 5 19:37:23 2016 -0800 | | | | Fix userinfo example presented in urllib2 howto. | | * | commit 10cbbbf | | Author: Yury Selivanov | | Date: Fri Feb 5 19:40:01 2016 -0500 | | | | Issue #26288: Optimize PyLong_AsDouble. | | * | commit e5185e7 | | Author: Eric V. Smith | | Date: Fri Feb 5 18:26:20 2016 -0500 | | | | Switch to more idiomatic C code. | | * | commit b59cb8f | | Author: Eric V. Smith | | Date: Fri Feb 5 18:23:08 2016 -0500 PS. git-remote-hg provides bidirectional transport. You can continue pulling from Mercurial repository(ies) and you can commit and push back to Mercurial repository(ies). Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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
