Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2 December 2014 at 01:38, Guido van Rossum gu...@python.org wrote: As far as I'm concerned I'm just waiting for your decision now. The RhodeCode team got in touch with me offline to suggest the possibility of using RhodeCode Enterprise as a self-hosted solution rather than a volunteer-supported installation of Kallithea. I'll be talking to them tomorrow, and if that discussion goes well, will update PEP 474 (and potentially PEP 462) accordingly. Given that that would take away the volunteer supported vs commercially supported distinction between self-hosting and using GitHub (as well as potentially building a useful relationship that may help us resolve other workflow issues in the future), I'd like us to hold off on any significant decisions regarding the fate of any of the repos until I've had a chance to incorporate the results of that discussion into my proposals. As described in PEP 474, I'm aware of the Mercurial team's concerns with RhodeCode's current licensing, but still consider it a superior alternative to an outright proprietary solution that doesn't get us any closer to solving the workflow problems with the main CPython repo. Regards, Nick. P.S. I'll also bring up some of the RFEs raised in this discussion around making it possible for folks to submit pull requests via GitHub/BitBucket, even if the master repositories are hosted on PSF infrastructure. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: 1. Move to GitHub 2. Move to Bitbucket 3. Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket) Regardless of what we do, I think we should graduate the mirrors on GitHub and Bitbucket to official -- for the proposed repos and cpython -- and get their repos updating per-push instead of as a cron job. I also think we should also flip on any CI we can (e.g. turn on Travis for GitHub along with coveralls support using coverage.py's encodings trick https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124). This will get us the most accessible repo backups as well as the widest tool coverage for contributors to assist them in their contributions (heck, even if we just get regular coverage reports for Python that would be a great win out of all of this). Now as for whether we should move the repos, I see two possibilities to help make that decision. One is we end up with 3 PEPs corresponding to the 3 proposals outlined above, get them done before PyCon, and then we have a discussion at the language summit where we can either make a decision or see what the pulse at the conference and sprints then make a decision shortly thereafter (I can moderate the summit discussion to keep this on-task and minimize the rambling; if Guido wants I can even make the final call since I have already played the role of villain for our issue tracker and hg decisions). The other option is we take each one of the 3 proposed repos and pilot/experiment with them on a different platform. I would put peps on GitHub (as per Guido's comment of getting PRs from there already), the devguide on Bitbucket, and leave devinabox on hg.python.org but with the motivation of getting better tooling in place to contribute to it. We can then see if anything changes between now and PyCon and then discuss what occurred there (if we can't get the word out about this experiment and get new tooling up and going on the issue tracker in the next 4 months then that's another data point about how much people do/don't care about any of this). Obviously if we end up needing more time we don't *have* to make a decision at PyCon, but it's a good goal to have. I don't think we can cleanly replicate a single repo on all three solutions as I sure don't want to deal with that merging fun (unless someone comes forward to be basically a release manager for one of the repos to make that experiment happen). So do people want PEPs or experimentation first? On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan ncogh...@gmail.com wrote: On 2 December 2014 at 01:38, Guido van Rossum gu...@python.org wrote: As far as I'm concerned I'm just waiting for your decision now. The RhodeCode team got in touch with me offline to suggest the possibility of using RhodeCode Enterprise as a self-hosted solution rather than a volunteer-supported installation of Kallithea. I'll be talking to them tomorrow, and if that discussion goes well, will update PEP 474 (and potentially PEP 462) accordingly. Given that that would take away the volunteer supported vs commercially supported distinction between self-hosting and using GitHub (as well as potentially building a useful relationship that may help us resolve other workflow issues in the future), I'd like us to hold off on any significant decisions regarding the fate of any of the repos until I've had a chance to incorporate the results of that discussion into my proposals. As described in PEP 474, I'm aware of the Mercurial team's concerns with RhodeCode's current licensing, but still consider it a superior alternative to an outright proprietary solution that doesn't get us any closer to solving the workflow problems with the main CPython repo. Regards, Nick. P.S. I'll also bring up some of the RFEs raised in this discussion around making it possible for folks to submit pull requests via GitHub/BitBucket, even if the master repositories are hosted on PSF infrastructure. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2014 11:50 AM, Brett Cannon wrote: So do people want PEPs or experimentation first? I'd vote for experimentation, to ground the discussion in actual practice. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlR99X8ACgkQ+gerLs4ltQ7dpACgsGq7Rii7seJXHCOVMUymbOdL 2KQAn3qcOGWynKU4rd/H39hpBxwSsbk9 =93kJ -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 2, 2014 at 9:23 AM, Tres Seaver tsea...@palladion.com wrote: I'd vote for experimentation, to ground the discussion in actual practice. +1. There may be a number of practical gotchas that very well might not surface in PEPs and should be documented and planned for. Likewise with benefits. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Thanks for taking charge, Brett. I personally think this shouldn't be brought up at the summit -- it's likely to just cause lots of heat about git vs. hg, free vs. not-free, loyalty to free or open tools, the weighing of core committers' preferences vs. outside contributors' preferences, GitHub's diversity track record, with no new information added. Even if we *just* had a vote by show-of-hands at the summit that would just upset those who couldn't be present. But I'll leave that up to you. The only thing I ask you is not to give me the last word. I might just do something you regret. :-) --Guido On Tue, Dec 2, 2014 at 8:50 AM, Brett Cannon br...@python.org wrote: So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: 1. Move to GitHub 2. Move to Bitbucket 3. Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket) Regardless of what we do, I think we should graduate the mirrors on GitHub and Bitbucket to official -- for the proposed repos and cpython -- and get their repos updating per-push instead of as a cron job. I also think we should also flip on any CI we can (e.g. turn on Travis for GitHub along with coveralls support using coverage.py's encodings trick https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124). This will get us the most accessible repo backups as well as the widest tool coverage for contributors to assist them in their contributions (heck, even if we just get regular coverage reports for Python that would be a great win out of all of this). Now as for whether we should move the repos, I see two possibilities to help make that decision. One is we end up with 3 PEPs corresponding to the 3 proposals outlined above, get them done before PyCon, and then we have a discussion at the language summit where we can either make a decision or see what the pulse at the conference and sprints then make a decision shortly thereafter (I can moderate the summit discussion to keep this on-task and minimize the rambling; if Guido wants I can even make the final call since I have already played the role of villain for our issue tracker and hg decisions). The other option is we take each one of the 3 proposed repos and pilot/experiment with them on a different platform. I would put peps on GitHub (as per Guido's comment of getting PRs from there already), the devguide on Bitbucket, and leave devinabox on hg.python.org but with the motivation of getting better tooling in place to contribute to it. We can then see if anything changes between now and PyCon and then discuss what occurred there (if we can't get the word out about this experiment and get new tooling up and going on the issue tracker in the next 4 months then that's another data point about how much people do/don't care about any of this). Obviously if we end up needing more time we don't *have* to make a decision at PyCon, but it's a good goal to have. I don't think we can cleanly replicate a single repo on all three solutions as I sure don't want to deal with that merging fun (unless someone comes forward to be basically a release manager for one of the repos to make that experiment happen). So do people want PEPs or experimentation first? On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan ncogh...@gmail.com wrote: On 2 December 2014 at 01:38, Guido van Rossum gu...@python.org wrote: As far as I'm concerned I'm just waiting for your decision now. The RhodeCode team got in touch with me offline to suggest the possibility of using RhodeCode Enterprise as a self-hosted solution rather than a volunteer-supported installation of Kallithea. I'll be talking to them tomorrow, and if that discussion goes well, will update PEP 474 (and potentially PEP 462) accordingly. Given that that would take away the volunteer supported vs commercially supported distinction between self-hosting and using GitHub (as well as potentially building a useful relationship that may help us resolve other workflow issues in the future), I'd like us to hold off on any significant decisions regarding the fate of any of the repos until I've had a chance to incorporate the results of that discussion into my proposals. As described in PEP 474, I'm aware of the Mercurial team's concerns with RhodeCode's current licensing, but still consider it a superior alternative to an outright proprietary solution that doesn't get us any closer to solving the workflow problems with the main CPython repo. Regards, Nick. P.S. I'll also bring up some of the RFEs raised in this discussion around making it possible for folks to submit pull requests via GitHub/BitBucket, even if the master repositories are hosted on PSF infrastructure. -- Nick Coghlan | ncogh...@gmail.com | Brisbane,
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum gu...@python.org wrote: Thanks for taking charge, Brett. I personally think this shouldn't be brought up at the summit -- it's likely to just cause lots of heat about git vs. hg, free vs. not-free, loyalty to free or open tools, the weighing of core committers' preferences vs. outside contributors' preferences, GitHub's diversity track record, with no new information added. Even if we *just* had a vote by show-of-hands at the summit that would just upset those who couldn't be present. Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. So if we did have a discussion at the summit and someone decided to argue for FLOSS vs. not as a key factor then I would politely cut them off and say that doesn't matter to me and move on. As I said, I would moderate the conversation to keep it on-task and not waste my time with points that have already been made and flagged by me and you as not deal-breakers. And any votes would be to gauge the feeling of the room and not as a binding decision; I assume either me or someone else is going to be the dictator on this and this won't be a majority decision. But I'll leave that up to you. The only thing I ask you is not to give me the last word. I might just do something you regret. :-) What about me doing something that *I* regret like taking this on? =) -Brett --Guido On Tue, Dec 2, 2014 at 8:50 AM, Brett Cannon br...@python.org wrote: So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: 1. Move to GitHub 2. Move to Bitbucket 3. Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket) Regardless of what we do, I think we should graduate the mirrors on GitHub and Bitbucket to official -- for the proposed repos and cpython -- and get their repos updating per-push instead of as a cron job. I also think we should also flip on any CI we can (e.g. turn on Travis for GitHub along with coveralls support using coverage.py's encodings trick https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124). This will get us the most accessible repo backups as well as the widest tool coverage for contributors to assist them in their contributions (heck, even if we just get regular coverage reports for Python that would be a great win out of all of this). Now as for whether we should move the repos, I see two possibilities to help make that decision. One is we end up with 3 PEPs corresponding to the 3 proposals outlined above, get them done before PyCon, and then we have a discussion at the language summit where we can either make a decision or see what the pulse at the conference and sprints then make a decision shortly thereafter (I can moderate the summit discussion to keep this on-task and minimize the rambling; if Guido wants I can even make the final call since I have already played the role of villain for our issue tracker and hg decisions). The other option is we take each one of the 3 proposed repos and pilot/experiment with them on a different platform. I would put peps on GitHub (as per Guido's comment of getting PRs from there already), the devguide on Bitbucket, and leave devinabox on hg.python.org but with the motivation of getting better tooling in place to contribute to it. We can then see if anything changes between now and PyCon and then discuss what occurred there (if we can't get the word out about this experiment and get new tooling up and going on the issue tracker in the next 4 months then that's another data point about how much people do/don't care about any of this). Obviously if we end up needing more time we don't *have* to make a decision at PyCon, but it's a good goal to have. I don't think we can cleanly replicate a single repo on all three solutions as I sure don't want to deal with that merging fun (unless someone comes forward to be basically a release manager for one of the repos to make that experiment happen). So do people want PEPs or experimentation first? On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan ncogh...@gmail.com wrote: On 2 December 2014 at 01:38, Guido van Rossum gu...@python.org wrote: As far as I'm concerned I'm just waiting for your decision now. The RhodeCode team got in touch with me offline to suggest the possibility of using RhodeCode Enterprise as a self-hosted solution rather than a volunteer-supported installation of
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 2, 2014 at 10:21 AM, Brett Cannon br...@python.org wrote: On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum gu...@python.org wrote: Thanks for taking charge, Brett. I personally think this shouldn't be brought up at the summit -- it's likely to just cause lots of heat about git vs. hg, free vs. not-free, loyalty to free or open tools, the weighing of core committers' preferences vs. outside contributors' preferences, GitHub's diversity track record, with no new information added. Even if we *just* had a vote by show-of-hands at the summit that would just upset those who couldn't be present. Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. So if we did have a discussion at the summit and someone decided to argue for FLOSS vs. not as a key factor then I would politely cut them off and say that doesn't matter to me and move on. As I said, I would moderate the conversation to keep it on-task and not waste my time with points that have already been made and flagged by me and you as not deal-breakers. And any votes would be to gauge the feeling of the room and not as a binding decision; I assume either me or someone else is going to be the dictator on this and this won't be a majority decision. But I'll leave that up to you. The only thing I ask you is not to give me the last word. I might just do something you regret. :-) What about me doing something that *I* regret like taking this on? =) I trust you more than myself in this issue, Brett. You'll do fine. I may just leave the room while it's being discussed. -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, 02 Dec 2014 18:21:39 + Brett Cannon br...@python.org wrote: So if we did have a discussion at the summit and someone decided to argue for FLOSS vs. not as a key factor then I would politely cut them off and say that doesn't matter to me and move on. As I said, I would moderate the conversation to keep it on-task and not waste my time with points that have already been made and flagged by me and you as not deal-breakers. And any votes would be to gauge the feeling of the room and not as a binding decision; I assume either me or someone else is going to be the dictator on this and this won't be a majority decision. Can we stop making decisions at summits where it's always the same people being present? Thanks Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. I think it's equally important to describe what criteria you will use to make this decision. E.g. are you saying all these above points will be completely ignored, or all else being equal, they will help tip the balance? Cheers, -Barry ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue Dec 02 2014 at 1:52:49 PM Antoine Pitrou solip...@pitrou.net wrote: On Tue, 02 Dec 2014 18:21:39 + Brett Cannon br...@python.org wrote: So if we did have a discussion at the summit and someone decided to argue for FLOSS vs. not as a key factor then I would politely cut them off and say that doesn't matter to me and move on. As I said, I would moderate the conversation to keep it on-task and not waste my time with points that have already been made and flagged by me and you as not deal-breakers. And any votes would be to gauge the feeling of the room and not as a binding decision; I assume either me or someone else is going to be the dictator on this and this won't be a majority decision. Can we stop making decisions at summits where it's always the same people being present? I already said I'm not going to make a decision there, but you have to admit having an in-person discussion is a heck of a lot easier than going back and forth in email and so I'm not willing to rule out at least talking about the topic at PyCon. I wouldn't hold it against a BDFAP talking about something at EuroPython and happening to make a decision while there and so I would expect the same courtesy. -Brett Thanks Antoine. ___ 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org wrote: On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. I think it's equally important to describe what criteria you will use to make this decision. E.g. are you saying all these above points will be completely ignored, or all else being equal, they will help tip the balance? Considering Guido just gave me this position I have not exactly had a ton of time to think the intricacies out, but they are all positives and can help tip the balance or break ties (I purposely worded all of that with prefer, etc.). For instance, if a FLOSS solution came forward that looked to be good and close enough to what would be a good workflow along with support commitments from the infrastructure team and folks to maintain the code -- and this will have to people several people as experience with the issue tracker has shown -- then that can help tip over the closed-source, hosted solution which might have some perks. As for Python over something else, that comes into play in open source more from a maintenance perspective, but for closed source it would be a tie-breaker only since it doesn't exactly influence the usability of the closed-source solution like it does an open-source one. Basically I'm willing to give brownie points for open source and Python stuff, but it is just that: points and not deal-breakers. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 2, 2014, at 2:09 PM, Brett Cannon br...@python.org wrote: On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org mailto:ba...@python.org wrote: On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. I think it's equally important to describe what criteria you will use to make this decision. E.g. are you saying all these above points will be completely ignored, or all else being equal, they will help tip the balance? Considering Guido just gave me this position I have not exactly had a ton of time to think the intricacies out, but they are all positives and can help tip the balance or break ties (I purposely worded all of that with prefer, etc.). For instance, if a FLOSS solution came forward that looked to be good and close enough to what would be a good workflow along with support commitments from the infrastructure team and folks to maintain the code -- and this will have to people several people as experience with the issue tracker has shown -- then that can help tip over the closed-source, hosted solution which might have some perks. As for Python over something else, that comes into play in open source more from a maintenance perspective, but for closed source it would be a tie-breaker only since it doesn't exactly influence the usability of the closed-source solution like it does an open-source one. Basically I'm willing to give brownie points for open source and Python stuff, but it is just that: points and not deal-breakers. This sounds like a pretty reasonable attitude to take towards this. If we’re going to be experimenting/talking things over, should I withdraw my PEP? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue Dec 02 2014 at 2:15:09 PM Donald Stufft don...@stufft.io wrote: On Dec 2, 2014, at 2:09 PM, Brett Cannon br...@python.org wrote: On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org wrote: On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. I think it's equally important to describe what criteria you will use to make this decision. E.g. are you saying all these above points will be completely ignored, or all else being equal, they will help tip the balance? Considering Guido just gave me this position I have not exactly had a ton of time to think the intricacies out, but they are all positives and can help tip the balance or break ties (I purposely worded all of that with prefer, etc.). For instance, if a FLOSS solution came forward that looked to be good and close enough to what would be a good workflow along with support commitments from the infrastructure team and folks to maintain the code -- and this will have to people several people as experience with the issue tracker has shown -- then that can help tip over the closed-source, hosted solution which might have some perks. As for Python over something else, that comes into play in open source more from a maintenance perspective, but for closed source it would be a tie-breaker only since it doesn't exactly influence the usability of the closed-source solution like it does an open-source one. Basically I'm willing to give brownie points for open source and Python stuff, but it is just that: points and not deal-breakers. This sounds like a pretty reasonable attitude to take towards this. If we’re going to be experimenting/talking things over, should I withdraw my PEP? No because only two people have said they like the experiment idea so that's not exactly enough to say it's worth the effort. =) Plus GitHub could be chosen in the end. Basically a PEP staying in draft is no big deal. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
I should say I will take a few days to think about this and then I will start a new thread outlining what I think we should be aiming for to help frame the whole discussion and to give proponents something to target. On Tue Dec 02 2014 at 2:20:16 PM Brett Cannon br...@python.org wrote: On Tue Dec 02 2014 at 2:15:09 PM Donald Stufft don...@stufft.io wrote: On Dec 2, 2014, at 2:09 PM, Brett Cannon br...@python.org wrote: On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org wrote: On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. I think it's equally important to describe what criteria you will use to make this decision. E.g. are you saying all these above points will be completely ignored, or all else being equal, they will help tip the balance? Considering Guido just gave me this position I have not exactly had a ton of time to think the intricacies out, but they are all positives and can help tip the balance or break ties (I purposely worded all of that with prefer, etc.). For instance, if a FLOSS solution came forward that looked to be good and close enough to what would be a good workflow along with support commitments from the infrastructure team and folks to maintain the code -- and this will have to people several people as experience with the issue tracker has shown -- then that can help tip over the closed-source, hosted solution which might have some perks. As for Python over something else, that comes into play in open source more from a maintenance perspective, but for closed source it would be a tie-breaker only since it doesn't exactly influence the usability of the closed-source solution like it does an open-source one. Basically I'm willing to give brownie points for open source and Python stuff, but it is just that: points and not deal-breakers. This sounds like a pretty reasonable attitude to take towards this. If we’re going to be experimenting/talking things over, should I withdraw my PEP? No because only two people have said they like the experiment idea so that's not exactly enough to say it's worth the effort. =) Plus GitHub could be chosen in the end. Basically a PEP staying in draft is no big deal. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/02/2014 11:21 AM, Brett Cannon wrote: I should say I will take a few days to think about this and then I will start a new thread outlining what I think we should be aiming for to help frame the whole discussion and to give proponents something to target. Thanks for taking this on, Brett. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote: No because only two people have said they like the experiment idea so that's not exactly enough to say it's worth the effort. =) Plus GitHub could be chosen in the end. Experimenting could be useful, although if the traffic is disproportionate (e.g. peps are updated way more often than devinabox) or folks don't interact with each of the repos, it might not be very representative. Still, I think it's better to get a visceral sense of how things actually work than to speculate about how they *might* work. Cheers, -Barry signature.asc Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Brett Cannon br...@python.org writes: Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. (and you've later clarified that these will all be factors weighing in favour of a candidate.) Thanks for expressing your thoughts. Big thanks for taking on the role of consulting, evaluating, and deciding on this issue. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__)—Bill Maher, 2003 | Ben Finney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/02/2014 08:50 AM, Brett Cannon wrote: So do people want PEPs or experimentation first? Experiments are good -- then we'll have real (if limited) data... which is better than no data. ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue Dec 02 2014 at 3:14:20 PM Barry Warsaw ba...@python.org wrote: On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote: No because only two people have said they like the experiment idea so that's not exactly enough to say it's worth the effort. =) Plus GitHub could be chosen in the end. Experimenting could be useful, although if the traffic is disproportionate (e.g. peps are updated way more often than devinabox) or folks don't interact with each of the repos, it might not be very representative. Still, I think it's better to get a visceral sense of how things actually work than to speculate about how they *might* work. That's my thinking. It's more about the workflow than measuring engagement on GitHub vs. Bitbucket (we already know how that skews). If I had my wish we would put the same repo in all three scenarios, but that is just asking for merge headaches. But I think if we go to the community and say, help us test dev workflows by submitting spelling and grammar fixes then we should quickly get an idea of the workflows (and I purposefully left devinabox out of a move since it is never touched after it essentially became a build script and a README and so represents our existing workflow; any benefit on our own infrastructure can go straight to cpython anyway which we can all experience). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 2, 2014 at 6:24 AM, Nick Coghlan ncogh...@gmail.com wrote: P.S. I'll also bring up some of the RFEs raised in this discussion around making it possible for folks to submit pull requests via GitHub/BitBucket, even if the master repositories are hosted on PSF infrastructure. In case it helps with any GH/BB-to-roundup/reitveld integration we might do, I've already done something similar for GH-to-reviewboard at work. All the code is on-line: https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension -eric ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon br...@python.org wrote: So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: Move to GitHub Move to Bitbucket Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket) I'd argue that option #3 here is somewhat orthogonal to switching hosting. It makes sense regardless unless we plan on ditching roundup and reitveld (to which I'd be opposed). Regardless of what we do, I think we should graduate the mirrors on GitHub and Bitbucket to official -- for the proposed repos and cpython -- and get their repos updating per-push instead of as a cron job. I also think we should also flip on any CI we can (e.g. turn on Travis for GitHub along with coveralls support using coverage.py's encodings trick). This will get us the most accessible repo backups as well as the widest tool coverage for contributors to assist them in their contributions (heck, even if we just get regular coverage reports for Python that would be a great win out of all of this). +1 to all of this. Doing this would allow us to move forward with GH/BB-roundup/reitveld integration (option #3) sooner rather than later, regardless of moving to other hosting. So do people want PEPs or experimentation first? +1 to PEPs. It's basically already happening. I'd like to see where 474/481/etc. end up, particularly with what Nick brought up earlier. Furthermore, I'm not sure how effectively we can experiment when it comes to moving hosting. There's overhead involved that biases the outcome and in part contributes to the momentum of the initial experimental conditions. I doubt any external solution is going to prove drastically better than another, making it harder to justify the effort to move yet again. -eric ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infrastructure. These environments are *very* different (App Engine has its own unique noSQL API) and it took a major hack (not by MvL) to get it to work outside App Engine. That fork is not supported, and hence our Rietveld installation still has various bugs that have long been squashed in the main Rietveld repo. (And no, I don't have time to help with this -- my recommendation is to move off Rietveld to something supported.) On Tue, Dec 2, 2014 at 2:33 PM, Eric Snow ericsnowcurren...@gmail.com wrote: On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon br...@python.org wrote: So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: Move to GitHub Move to Bitbucket Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket) I'd argue that option #3 here is somewhat orthogonal to switching hosting. It makes sense regardless unless we plan on ditching roundup and reitveld (to which I'd be opposed). Regardless of what we do, I think we should graduate the mirrors on GitHub and Bitbucket to official -- for the proposed repos and cpython -- and get their repos updating per-push instead of as a cron job. I also think we should also flip on any CI we can (e.g. turn on Travis for GitHub along with coveralls support using coverage.py's encodings trick). This will get us the most accessible repo backups as well as the widest tool coverage for contributors to assist them in their contributions (heck, even if we just get regular coverage reports for Python that would be a great win out of all of this). +1 to all of this. Doing this would allow us to move forward with GH/BB-roundup/reitveld integration (option #3) sooner rather than later, regardless of moving to other hosting. So do people want PEPs or experimentation first? +1 to PEPs. It's basically already happening. I'd like to see where 474/481/etc. end up, particularly with what Nick brought up earlier. Furthermore, I'm not sure how effectively we can experiment when it comes to moving hosting. There's overhead involved that biases the outcome and in part contributes to the momentum of the initial experimental conditions. I doubt any external solution is going to prove drastically better than another, making it harder to justify the effort to move yet again. -eric -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org wrote: Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infrastructure. These environments are *very* different (App Engine has its own unique noSQL API) and it took a major hack (not by MvL) to get it to work outside App Engine. That fork is not supported, and hence our Rietveld installation still has various bugs that have long been squashed in the main Rietveld repo. (And no, I don't have time to help with this -- my recommendation is to move off Rietveld to something supported.) It probably makes sense to include code reviews in the matrix of what tools we’re going to use then yea? Like Github/Bitbucket/etc have review built in. Other tools like Phabricator do as well but are self hosted instead. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/02/2014 02:47 PM, Donald Stufft wrote: On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org mailto:gu...@python.org wrote: Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infrastructure. These environments are *very* different (App Engine has its own unique noSQL API) and it took a major hack (not by MvL) to get it to work outside App Engine. That fork is not supported, and hence our Rietveld installation still has various bugs that have long been squashed in the main Rietveld repo. (And no, I don't have time to help with this -- my recommendation is to move off Rietveld to something supported.) It probably makes sense to include code reviews in the matrix of what tools we’re going to use then yea? Like Github/Bitbucket/etc have review built in. Other tools like Phabricator do as well but are self hosted instead. I think the people/company behind phabricator are planning to offer an hosting solution. Could be worth poking at them to have and idea of what is the status of it. -- Pierre-Yves David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 3 Dec 2014 08:47, Donald Stufft don...@stufft.io wrote: On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org wrote: Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infrastructure. These environments are *very* different (App Engine has its own unique noSQL API) and it took a major hack (not by MvL) to get it to work outside App Engine. That fork is not supported, and hence our Rietveld installation still has various bugs that have long been squashed in the main Rietveld repo. (And no, I don't have time to help with this -- my recommendation is to move off Rietveld to something supported.) Thanks Guido - I'd started thinking in that direction for PEP 462 (in terms of potentially using Kallithea/RhodeCode for the review component rather than Reitveld), so it's good to know you'd be OK with such a change. It probably makes sense to include code reviews in the matrix of what tools we’re going to use then yea? I'd suggest asking for discussion of a more general path forward for CPython workflow improvements. Not a this must be included in the proposal, but rather answering the question, if we choose this option for the support repos, how will it impact the future direction of CPython maintenance itself?. Cheers, Nick. Like Github/Bitbucket/etc have review built in. Other tools like Phabricator do as well but are self hosted instead. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, 30 Nov 2014 22:06:03 -0500 Terry Reedy tjre...@udel.edu wrote: If the mirror experiment is successful, the devguide might be the next experiment. It does not have any one maintainer, and *is* tied to the tracker. But herein lies the problem with the devguide. There are 22 issues, down just 1 from about a year ago. All but 2 are more than a year old. Many (most?) have patches, but enough consensus for anyone to push is hard. As with other doc issues, there is no 'test' for when a non-trivial patch is 'good enough' and hence, in my opinion, too much bikeshedding and pursuit of the perfect. Speaking as someone who contributed to the devguide, I think it has become good enough and have therefore largely stopped caring. Also, many requests seem to be of the please add this thing kind, which is a slippery slope. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-11-30, 11:18 GMT, Ben Finney wrote: Donald Stufft don...@stufft.io writes: I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. GitHub deliberately encourages proprietary features that create valuable data that cannot be exported — the proprietary GitHub-specific pull requests being a prime example. What I really don’t understand is why this discussion is hg v. GitHub, when it should be hg v. git. Particular hosting is a secondary issue and it could be GitHub or git.python.org (with some FLOSS git hosting package ... cgit/gitolite, gitorious, gitlab, etc.) or python.gitorious.org (I believe Gitorious people might be happy to host you) or whatever else. Best, Matěj ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: Migrating the DVCS content is usually easy. This is lovely mantra, but do you speak from your own experience? I did move rope from Bitbucket to https://github.com/python-rope and it was A LOT of work (particularly issues, existing pull requests, and other related stuff like many websites the projects holds). And rope is particularly simple (and almost dead so inactive) project. Best, Matěj ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 00:50 GMT, Donald Stufft wrote: The only thing that is true is that git users are more likely to use the ability to rewrite history than Mercurial users are, but you’ll typically find that people generally don’t do this on public branches, only on private branches. And I would add that any reasonable git repository manager (why we are talking only about GitHub as if there was no cgit, gitorious, gitlab, gitblit, etc.?) can forbid forced-push so the history could be as sacrosanct as with Mercurial. Matěj ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, 1 Dec 2014 08:46:46 +0100 Matěj Cepl mc...@cepl.eu wrote: On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: Migrating the DVCS content is usually easy. This is lovely mantra, but do you speak from your own experience? I did move rope from Bitbucket to https://github.com/python-rope and it was A LOT of work (particularly issues, existing pull requests, and other related stuff like many websites the projects holds). He did say DVCS content (as in: stuff that's stored in git or hg), not ancillary data such as pull requests, issues, wikis and Web sites. But you're making his point: migrating a source code repository from hg to git or vice-versa is relatively easy, it's the surrounding stuff that's hard. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 02:56:22PM -0500, Donald Stufft wrote: As I mentioned in my other email, we’re already supporting two different tools, and it’s a hope of mine to use this as a sort of testbed to moving the other repositories as well. If we go down this path, can we have some *concrete* and *objective* measures of success? If moving to git truly does improve things, then the move can be said to be a success. But if it makes no concrete difference, then we've wasted our time. In six months time, how will we know which it is? Can we have some concrete and objective measures of what would count as success, and some Before and After measurements? Just off the top of my head... if the number of documentation patches increases significiantly (say, by 30%) after six months, that's a sign the move was successful. It's one thing to say that using hg is discouraging contributors, and that hg is much more popular. It's another thing to say that moving to git will *actually make a difference*. Maybe all the would-be contributors using git are too busy writing kernel patches for Linus or using Node.js and wouldn't be caught dead with Python :-) With concrete and objective measures of success, you will have ammunition to suggest moving the rest of Python to git in a few years time. And without it, we'll also have good evidence that any further migration to git may be a waste of time and effort and we should focus our energy elsewhere rather than git vs hg holy wars. [...] I also think it’s hard to look at a company like bitbucket, for example, and say they are *better* than Github just because they didn’t have a public and inflammatory event. We can't judge companies on what they might be doing behind closed doors, only on what we can actually see of them. Anybody might be rotten bounders and cads in private, but how would we know? It's an imperfect world and we have imperfect knowledge but still have to make a decision as best we can. Attempting to reduce the cognitive burden for contributing and aligning ourselves with the most popular tools allows us to take advantage of the network effects of these tools popularity. This can be the difference between someone with limited amount of time being able to contribute or not, which can make real inroads towards making it easier for under privileged people to contribute much more than refusing to use a product of one group of people over another just because the other group hasn’t had a public and inflammatory event. In other contexts, that could be a pretty awful excuse for inaction against the most aggregiously bad behaviour. Sure, Acme Inc might have adulterated baby food with arsenic, but other companies might have done worse things that we haven't found out about. So we should keep buying Acme's products, because they're cheaper and that's good for the poor. Not that I'm comparing GitHub's actions with poisoning babies. What GitHub did was much worse. *wink* -- Steven ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 02, 2014 at 12:37:22AM +1100, Steven D'Aprano wrote: [...] It's one thing to say that using hg is discouraging contributors, and that hg is much more popular. /s/more/less/ -- Steven ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 1, 2014 at 12:25 AM, Ethan Furman et...@stoneleaf.us wrote: One argument that keeps coming up is transferability of knowledge: knowing git and/or GitHub, as many seem to, it therefore becomes easier to commit to the Python ecosystem. What about the transferability of Python knowledge? Because I know Python, I can customize hg; because I know Python I can customize Roundup. I do not choose tools simply because they are written in Python -- I choose them because, being written in Python, I can work on them if I need to: I can enhance them, I can fix them, I can learn from them. There are lots of Python tools written with Git: * https://pypi.python.org/pypi/vcs * https://pypi.python.org/pypi/dulwich * https://pypi.python.org/pypi/hg-git * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html (GitFS) * https://github.com/libgit2/pygit2 (C) * https://pypi.python.org/pypi/GitPython (Python) * https://pypi.python.org/pypi/pyrpo (subprocess wrapper for git, hg, bzr, svn) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum gu...@python.org wrote: Can we please stop the hg-vs-git discussion? We've established earlier that the capabilities of the DVCS itself (hg or git) are not a differentiator, and further he-said-she-said isn't going to change anybody's opinion. +1 from me as well. I view this as a discussion of platforms and not DVCSs. What's left is preferences of core developers, possibly capabilities of the popular websites (though BitBucket vs. GitHub seems to be a wash as well), and preferences of contributors who aren't core developers (using popularity as a proxy). It seems the preferences of the core developers are mixed, while the preferences of non-core contributors are pretty clear, so we have a problem weighing these two appropriately. Also, let's not get distracted by the needs of the CPython repo, issue tracker, and code review tool. Arguments about core developers vs. contributors for CPython shouldn't affect the current discussion. Next, two of the three repos mentioned in Donald's PEP 481 are owned by Brett Cannon, according to the Contact column listed on hg.python.org. I propose to let Brett choose whether to keep these on hg.python.org, move to BitBucket, or move to GitHub. @Brett, what say you? (Apart from I'm tired of the whole thread. :-) You do one or two nice things for python-dev and you end up being saddled with them for life. ;) Sure, I can handle the devguide and devinabox decisions since someone has to and it isn't going to be more fun for someone else compared to me. The third one is the peps repo, which has python-dev@python.org as Contact. It turns out that Nick is by far the largest contributor (he committed 215 of the most recent 1000 changes) so I'll let him choose. Perk of all those packaging PEPs. Finally, I'd like to get a few more volunteers for the PEP editors list, preferably non-core devs: the core devs are already spread too thinly, and I really shouldn't be the one who picks new PEP numbers and checks that PEPs are well-formed according to the rules of PEP 1. A PEP editor shouldn't have to pass judgment on the contents of a PEP (though they may choose to correct spelling and grammar). Knowledge of Mercurial is a plus. :-) And based on how Nick has been talking, will continue to be at least in the medium term. =) -Brett On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 7:43 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: It’s not lost, [… a long, presumably-accurate discourse of the many conditions that must be met before …] you can restore it. This isn't the place to discuss the details of Git's internals, I think. I'm merely pointing out that: The important thing to realize is that a “branch” isn’t anything special in git. Because of that, Ethan's impression – that Git's default behaviour encourages losing history (by re-writing the history of commits to be other than what they were) is true, and “Git never loses history” simply isn't true. Whether that is a *problem* is a matter of debate, but the fact that Git's common workflow commonly discards information that some consider valuable, is a simple fact. If Ethan chooses to make that a factor in his decisions about Git, the facts are on his side. Except it’s not true at all. That data is all still there if you want it to exist and it’s not a real differentiator between Mercurial and git because Mercurial has the ability to do the same thing. Never mind the fact that “lose” your history makes it sound accidental instead of on purpose. It’s like saying that ``rm foo.txt`` will “lose” the data in foo.txt. So either it was a misunderstanding in which case I wanted to point out that those operations don’t magically lose information or it’s a purposely FUDish statement in which case I want to point out that the statement is inaccurate. The only thing that is true is that git users are more likely to use the ability to rewrite history than Mercurial users are, but you’ll typically find that people generally don’t do this on public branches, only on private branches. Which again doesn’t make much sense in this context since generally currently the way people are using Mercurial with CPython you’re using patches to transfer the changes from the contributor to the committer so you’re “losing” that history regardless. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
As far as I'm concerned I'm just waiting for your decision now. On Mon, Dec 1, 2014 at 7:07 AM, Brett Cannon br...@python.org wrote: On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum gu...@python.org wrote: Can we please stop the hg-vs-git discussion? We've established earlier that the capabilities of the DVCS itself (hg or git) are not a differentiator, and further he-said-she-said isn't going to change anybody's opinion. +1 from me as well. I view this as a discussion of platforms and not DVCSs. What's left is preferences of core developers, possibly capabilities of the popular websites (though BitBucket vs. GitHub seems to be a wash as well), and preferences of contributors who aren't core developers (using popularity as a proxy). It seems the preferences of the core developers are mixed, while the preferences of non-core contributors are pretty clear, so we have a problem weighing these two appropriately. Also, let's not get distracted by the needs of the CPython repo, issue tracker, and code review tool. Arguments about core developers vs. contributors for CPython shouldn't affect the current discussion. Next, two of the three repos mentioned in Donald's PEP 481 are owned by Brett Cannon, according to the Contact column listed on hg.python.org. I propose to let Brett choose whether to keep these on hg.python.org, move to BitBucket, or move to GitHub. @Brett, what say you? (Apart from I'm tired of the whole thread. :-) You do one or two nice things for python-dev and you end up being saddled with them for life. ;) Sure, I can handle the devguide and devinabox decisions since someone has to and it isn't going to be more fun for someone else compared to me. The third one is the peps repo, which has python-dev@python.org as Contact. It turns out that Nick is by far the largest contributor (he committed 215 of the most recent 1000 changes) so I'll let him choose. Perk of all those packaging PEPs. Finally, I'd like to get a few more volunteers for the PEP editors list, preferably non-core devs: the core devs are already spread too thinly, and I really shouldn't be the one who picks new PEP numbers and checks that PEPs are well-formed according to the rules of PEP 1. A PEP editor shouldn't have to pass judgment on the contents of a PEP (though they may choose to correct spelling and grammar). Knowledge of Mercurial is a plus. :-) And based on how Nick has been talking, will continue to be at least in the medium term. =) -Brett On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 7:43 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: It’s not lost, [… a long, presumably-accurate discourse of the many conditions that must be met before …] you can restore it. This isn't the place to discuss the details of Git's internals, I think. I'm merely pointing out that: The important thing to realize is that a “branch” isn’t anything special in git. Because of that, Ethan's impression – that Git's default behaviour encourages losing history (by re-writing the history of commits to be other than what they were) is true, and “Git never loses history” simply isn't true. Whether that is a *problem* is a matter of debate, but the fact that Git's common workflow commonly discards information that some consider valuable, is a simple fact. If Ethan chooses to make that a factor in his decisions about Git, the facts are on his side. Except it’s not true at all. That data is all still there if you want it to exist and it’s not a real differentiator between Mercurial and git because Mercurial has the ability to do the same thing. Never mind the fact that “lose” your history makes it sound accidental instead of on purpose. It’s like saying that ``rm foo.txt`` will “lose” the data in foo.txt. So either it was a misunderstanding in which case I wanted to point out that those operations don’t magically lose information or it’s a purposely FUDish statement in which case I want to point out that the statement is inaccurate. The only thing that is true is that git users are more likely to use the ability to rewrite history than Mercurial users are, but you’ll typically find that people generally don’t do this on public branches, only on private branches. Which again doesn’t make much sense in this context since generally currently the way people are using Mercurial with CPython you’re using patches to transfer the changes from the contributor to the committer so you’re “losing” that history regardless. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/guido%40python.org --
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 07:43 GMT, Donald Stufft wrote: I do not choose tools simply because they are written in Python -- I choose them because, being written in Python, I I can work on them if I need to: I can enhance them, I can fix them, I can learn from them. Git uses the idea of small individual commands that do small things, so you can write your own commands that work on text streams to extend git and you can even write those in Python. I really really dislike this Mercurial propaganda for two reasons: a) obviously you are right ... git is a complete tool box for building your own tools in the best UNIX™ traditions. Each of has a ton of third-party (or our own) tools using git plumbing. (Is there a Mercurial equivalent of git-filter-branch? Can http://mercurial.selenic.com/wiki/ConvertExtension do the same as git-filter-branch?) b) it completely ignores existence of three (3) independent implementations of git format/protocol (also jgit and libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support for hg works? Does it use a library or just runs hg binary in a subprocess (a thing which by the hg authors is Mercurial not designed to do)? Best, Matěj ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Here's a roundup of tools links, to make sure we're all on the same page: Git HG Rosetta Stone === https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone BugWarrior === BugWarrior works with many issue tracker APIs https://warehouse.python.org/project/bugwarrior/ bugwarrior is a command line utility for updating your local taskwarrior database from your forge issue trackers. It currently supports the following remote resources: - github (api v3) - bitbucket - trac - bugzilla - megaplan - teamlab - redmine - jira - activecollab (2.x and 4.x) - phabricator [...] DVCS Interaction Hg - Git * https://warehouse.python.org/project/hg-git/ (dulwich) * hg-github https://github.com/stephenmcd/hg-github Git - Hg -- * https://pypi.python.org/pypi/git-remote-hg/ * https://github.com/felipec/git-remote-hg Python - Hg --- | Wikipedia: https://en.wikipedia.org/wiki/Mercurial | Homepage: http://hg.selenic.org/ | Docs: http://mercurial.selenic.com/guide | Docs: http://hgbook.red-bean.com/ | Source: hg http://selenic.com/hg | Source: hg http://hg.intevation.org/mercurial/crew * http://evolution.experimentalworks.net/doc/user-guide.html * (growing list of included extensions) Python - Git -- * GitPython, pygit2 (libgit2), dulwich * https://github.com/libgit2/pygit2 (libgit2) * https://pythonhosted.org/GitPython/ (Python) * https://github.com/jelmer/dulwich (Python) * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#installing-dependencies GitHub - BitBucket - * https://bitbucket.org/ZyX_I/gibiexport Sphinx Documentation * http://read-the-docs.readthedocs.org/en/latest/webhooks.html * https://github.com/yoloseem/awesome-sphinxdoc * changelogs, charts, csv, ipython, %doctest_mode Is there an issue ticket or a wiki page that supports Markdown/ReStructuredText, where I could put this? Which URI do we assign to this artifact? On Mon, Dec 1, 2014 at 8:37 AM, Wes Turner wes.tur...@gmail.com wrote: On Mon, Dec 1, 2014 at 12:25 AM, Ethan Furman et...@stoneleaf.us wrote: One argument that keeps coming up is transferability of knowledge: knowing git and/or GitHub, as many seem to, it therefore becomes easier to commit to the Python ecosystem. What about the transferability of Python knowledge? Because I know Python, I can customize hg; because I know Python I can customize Roundup. I do not choose tools simply because they are written in Python -- I choose them because, being written in Python, I can work on them if I need to: I can enhance them, I can fix them, I can learn from them. There are lots of Python tools written with Git: * https://pypi.python.org/pypi/vcs * https://pypi.python.org/pypi/dulwich * https://pypi.python.org/pypi/hg-git * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html (GitFS) * https://github.com/libgit2/pygit2 (C) * https://pypi.python.org/pypi/GitPython (Python) * https://pypi.python.org/pypi/pyrpo (subprocess wrapper for git, hg, bzr, svn) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/01/2014 01:05 PM, Matěj Cepl wrote: On 2014-12-01, 07:43 GMT, Donald Stufft wrote: I do not choose tools simply because they are written in Python -- I choose them because, being written in Python, I I can work on them if I need to: I can enhance them, I can fix them, I can learn from them. Git uses the idea of small individual commands that do small things, so you can write your own commands that work on text streams to extend git and you can even write those in Python. I really really dislike this Mercurial propaganda for two reasons: a) obviously you are right ... git is a complete tool box for building your own tools in the best UNIX™ traditions. Each of has a ton of third-party (or our own) tools using git plumbing. (Is there a Mercurial equivalent of git-filter-branch? Can http://mercurial.selenic.com/wiki/ConvertExtension do the same as git-filter-branch?) b) it completely ignores existence of three (3) independent implementations of git format/protocol (also jgit and libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support for hg works? Does it use a library or just runs hg binary in a subprocess (a thing which by the hg authors is Mercurial not designed to do)? Please at least try to get your facts right. For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface. http://mercurial.selenic.com/wiki/MercurialApi Georg ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/01/2014 08:42 AM, Wes Turner wrote: Here's a roundup of tools links, to make sure we're all on the same page: Thanks! -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Hi! On Mon, Dec 01, 2014 at 10:42:16AM -0600, Wes Turner wes.tur...@gmail.com wrote: Here's a roundup of tools links, to make sure we're all on the same page: Very nice! Is there an issue ticket or a wiki page that supports Markdown/ReStructuredText, where I could put this? Which URI do we assign to this artifact? There are already pages https://wiki.python.org/moin/Git and https://wiki.python.org/moin/Mercurial . You can create an additional page and reference it on that pages. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/1/2014 11:42 AM, Wes Turner wrote: Here's a roundup of tools links, to make sure we're all on the same page: Git HG Rosetta Stone === https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone BugWarrior === BugWarrior works with many issue tracker APIs https://warehouse.python.org/project/bugwarrior/ bugwarrior is a command line utility for updating your local taskwarrior database from your forge issue trackers. It currently supports the following remote resources: * github (api v3) * bitbucket * trac * bugzilla * megaplan * teamlab * redmine * jira * activecollab (2.x and 4.x) * phabricator [...] DVCS Interaction Hg - Git * https://warehouse.python.org/project/hg-git/ (dulwich) * hg-github https://github.com/stephenmcd/hg-github Git - Hg -- * https://pypi.python.org/pypi/git-remote-hg/ * https://github.com/felipec/git-remote-hg Python - Hg --- | Wikipedia: https://en.wikipedia.org/wiki/Mercurial | Homepage: http://hg.selenic.org/ | Docs: http://mercurial.selenic.com/guide | Docs: http://hgbook.red-bean.com/ | Source: hg http://selenic.com/hg | Source: hg http://hg.intevation.org/mercurial/crew * http://evolution.experimentalworks.net/doc/user-guide.html * (growing list of included extensions) Python - Git -- * GitPython, pygit2 (libgit2), dulwich * https://github.com/libgit2/pygit2 (libgit2) * https://pythonhosted.org/GitPython/ (Python) * https://github.com/jelmer/dulwich (Python) * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#installing-dependencies GitHub - BitBucket - * https://bitbucket.org/ZyX_I/gibiexport Sphinx Documentation * http://read-the-docs.readthedocs.org/en/latest/webhooks.html * https://github.com/yoloseem/awesome-sphinxdoc * changelogs, charts, csv, ipython, %doctest_mode Is there an issue ticket or a wiki page that supports https://wiki.python.org/moin/ Markdown/ReStructuredText, whoops, I am not sure what moin uses. where I could put this? Which URI do we assign to this artifact? -- 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 01, 2014 at 03:52:21PM -0500, Terry Reedy tjre...@udel.edu wrote: On 12/1/2014 11:42 AM, Wes Turner wrote: Is there an issue ticket or a wiki page that supports https://wiki.python.org/moin/ Markdown/ReStructuredText, whoops, I am not sure what moin uses. Let's see... https://wiki.python.org/moin/?action=raw Seems like reST. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 10:25 AM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 1:05 PM, Guido van Rossum gu...@python.org wrote: I don't feel it's my job to accept or reject this PEP, but I do have an opinion. So here’s a question. If it’s not your job to accept or reject this PEP, whose is it? This is probably an issue we’re never going to get actual consensus on so unless there is an arbitrator of who gets to decide I feel it’s probably a waste of my time to try and convince absolutely *everyone*. I saved this question. I still don't know who should accept or reject the PEP. I tried to get out of it by asking Brett for the two repos he owns, but he hasn't stated his preference (though he did acknowledge the responsibility). If it were really up to me I'd switch all minor repos to GitHub, but I feel I've run into sufficient opposition (most vocally from Nick) that I think status quo wins applies. I think Nick previously wanted to switch to BitBucket -- if he hasn't hardened his position I say we should do that. But if he no longer wants that, I have stopped caring after the 200th message. -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/29/2014 04:37 PM, Donald Stufft wrote: On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@gmail.com wrote: Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don’t know how to do this. Instead of collectively scratching your heads, could one of you guys do the research and figure out whether or not hg supports this workflow? One of the following two things must be true: 1. hg supports this workflow (or a reasonable fascimile), which may lessen the need for this PEP. 2. hg doesn't support this workflow, which may strengthen the need for this PEP. Saying I've been using hg for years and I don't know whether it supports this IMPORTANT THING is not a particularly compelling argument. //arry/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 29 Nov 20:13, Donald Stufft wrote: I think one of the issues with Reitveld isn’t related to Reitveld itself at all, it’s all the *other* stuff you have to do to get a patch into Reitveld to allow someone to review it at all. Generating a patch and uploading it to Roundup is a pain and it’s far easier to just commit things directly to default. For the record, there is a mercurial extension to ease upload of patch to Rietveld: https://bitbucket.org/nicoe/hgreview/overview -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgpHacKBDr5lJ.pgp Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote: Python is already using quite a bit of non-free software in its ecosystem. The Windows builds of CPython are made with Microsoft's compiler, and the recent discussion about shifting to Cygwin or MinGW basically boiled down to but it ought to be free software, and that was considered not a sufficiently strong argument. In each case, the decision has impact on other people (using MSVC for the official python.org installers means extension writers need to use MSVC too; and using GitHub means that contributors are strongly encouraged, possibly required, to use GitHub); so why is it acceptable to use a non-free compiler, but not acceptable to use a non-free host? Relying on non-free software to support users of a non-free platform is rather different from *requiring* the use of non-free software to participate in core Python community design processes. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan ncogh...@gmail.com wrote: On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote: Python is already using quite a bit of non-free software in its ecosystem. The Windows builds of CPython are made with Microsoft's compiler, and the recent discussion about shifting to Cygwin or MinGW basically boiled down to but it ought to be free software, and that was considered not a sufficiently strong argument. In each case, the decision has impact on other people (using MSVC for the official python.org installers means extension writers need to use MSVC too; and using GitHub means that contributors are strongly encouraged, possibly required, to use GitHub); so why is it acceptable to use a non-free compiler, but not acceptable to use a non-free host? Relying on non-free software to support users of a non-free platform is rather different from *requiring* the use of non-free software to participate in core Python community design processes. But what non-free software is required to use the community design processes? The GitHub client is entirely optional; I don't use it, I just use git itself. Using a free client to access a proprietary server isn't the same as using non-free software. ChrisA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
I have some questions and/or issues with the PEP, but first I'm going to add something to Nick's comments: On Sun, Nov 30, 2014 at 11:12:17AM +1000, Nick Coghlan wrote: Beyond that, GitHub is indeed the most expedient option. My two main reasons for objecting to taking the expedient path are: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. While I admire the ingenuity of the free-as-in-beer model for proprietary software companies fending off open source competition, I still know a proprietary platform play when I see one (and so do venture capitalists looking to extract monopoly rents from the industry in the future). (So yes, I regret relenting on this principle in previously suggesting the interim use of another proprietary hosted service) 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team to resolve their documentation and usability issues rather than just yelling at them your tool isn't popular enough for us, and we find certain aspects of it too hard to use, so we're switching to something else rather than working with you to address our concerns. We consider the Mercurial team a significant enough part of the Python ecosystem that Matt was one of the folks specifically invited to the 2014 language summit to discuss their concerns around the Python 3 transition. Yet we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? (And yes, I consider some of the core Mercurial devs to be friends, so this isn't an entirely abstract concern for me) Thanks Nick, I think these are excellent points, particularly the second. It would be a gross strawman to say that we should only use software developed in Python, but we should eat our own dogfood whenever practical and we should support and encourage the Python ecosystem, including Mercurial. Particularly since hg and git are neck and neck feature-wise, we should resist the tendency to jump on bandwagons. If git were clearly the superior product, then maybe there would be an argument for using the best tool for the job, but it isn't. As for the question of using Github hosting, there's another factor which has been conspicuous by its absence. Has GitHub's allegedly toxic and bullying culture changed since Julie Horvath quit in March? And if it has not, do we care? I'm not a saint, but I do try to choose ethical companies and institutions over unethical ones whenever it is possible and practical. I'm not looking for a witch-hunt against GitHub, but if the allegations made by Horvath earlier this year are true, and I don't believe anyone has denied them, then so long as GitHub's internal culture remains sexist and hostile to the degree reported, then I do not believe that we should use GitHub's services even if we shift some repos to git. I have serious doubts about GitHub's compatibility with the ideals expressed by the PSF. Even if our code of conduct does not explicitly forbid it, I think that it goes against the principles that we say we aspire to. Given Horvath's experiences, and the lack of clear evidence that anything has changed in GitHub, I would be deeply disappointed if Python lent even a smidgeon of legitimacy to their company, and I personally will not use their services. I acknowledge that it's hard to prove a negative, and GitHub may have difficulty proving to my satisfaction that they have changed. (My experience is that company culture rarely changes unless there is a change in management, and even then only slowly.) Particularly given GitHub's supposed egalitarian, non-hierarchical, and meritocratic structure, that nobody apparently saw anything wrong with the bullying of staff and workplace sexism until it became public knowledge suggests that it is not just a few bad apples but a problem all through the company. -- Steven ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Chris Angelico ros...@gmail.com writes: But what non-free software is required to use the community design processes? The GitHub client is entirely optional; I don't use it, I just use git itself. Using a free client to access a proprietary server isn't the same as using non-free software. For that to remain true, there must be no advantage specifically to GitHub except as a commodity repository host. So all the verbiage about specific GitHub features in this PEP are undermined. On the other hand, if GitHub is being recommended specifically because of features that cannot be migrated elsewhere (such as its proprietary pull requests), then it is not possible to argue that Git alone is sufficient to realise these advantages. -- \ “DRM doesn't inconvenience [lawbreakers] — indeed, over time it | `\ trains law-abiding users to become [lawbreakers] out of sheer | _o__)frustration.” —Charles Stross, 2010-05-09 | Ben Finney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft don...@stufft.io writes: I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. GitHub deliberately encourages proprietary features that create valuable data that cannot be exported — the proprietary GitHub-specific pull requests being a prime example. So it is only true to say one can export the data to a different host if one entirely abandons all those features which create GitHub-proprietary data. If you want to re-write the PEP to be clear you are only talking about the repository hosting of GitHub, and *not* any of its extra features that make it so attractive to use their proprietary service, I'd be interested to see that. On the other hand, if you want to promote those proprietary features as part of the PEP, then it is disingenuous to claim the data can be easily exported to a different host. -- \“Do not enter the lift backwards, and only when lit up.” | `\—elevator, Leipzig | _o__) | Ben Finney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. Paul ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. So I usually choose not to weigh in on discussions like these but there seems to be a lot of misdirection in some of these arguments. To start, I'm generally neutral about this proposal or Nick's proposal that spurred this one. I've found the most frustrating part of contributing to anything involving CPython to be the lack of reviewer time. I have had very small (2-line) patches take months (close to a year in reality) to get through in spite of periodically pinging the appropriate people. Moving to git/GitHub will not alleviate this at all. To be clear, the main reasoning behind Nick's was being able to submit changes without ever having to have a local copy of the repository in question on your machine. Having a complete web workflow for editing and contributing makes the barrier to entry far lower than switching VCS or anything else. BitBucket (apparently, although I've never used this) and GitHub both have this capability and *both* are free-as-in-beer systems. No one as I understand it is proposing that we use the per-distro proprietary interface to these websites. All data can be removed from GitHub using it's API and can generally be converted to another platform. The same goes for BitBucket although it's arguably easier to retrieve issue data from BitBucket than GitHub. That said, *the issue tracker is not covered by these proposals* so this is a moot point. Drop it already. If we're seriously considering moving to git as a DVCS, we should consider the real free-as-in-freedom alternatives that come very close to GitHub and can be improved by us (even though they're not written in Python). One of those is GitLab. We can self-host a GitLab instance easily or we can rely on gitlab.com. GitLab aims to provide a very similar user experience to GitHub and it's slowly approaching feature parity and experience parity. GitLab is also what a lot of people chose to switch to after the incident Steven mentioned, which I don't think is something we should dismiss or ignore. We should refocus the discussion with the following in mind: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process - GitHub has a toxic company culture that we should be aware of before moving to it. They have a couple blog posts about attempting to change it but employees became eerily silent after the incident and have remained so from what I've personally seen. - GitHub may be popular but there are popular FOSS solutions that exist that we can also self-host at something like forge.python.org - bugs.python.org is not covered by any of these proposals - The main benefit this proposal (and the proposal to move to BitBucket) are seeking to achieve is an online editing experience allowing for *anyone with a browser and an account* to contribute. This to me is the only reason I would be +1 for either of these proposals (if we can reach consensus). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Larry Hastings la...@hastings.org writes: On 11/29/2014 04:37 PM, Donald Stufft wrote: On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@gmail.com wrote: Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don’t know how to do this. Instead of collectively scratching your heads, could one of you guys do the research and figure out whether or not hg supports this workflow? One of the following two things must be true: 1. hg supports this workflow (or a reasonable fascimile), which may lessen the need for this PEP. 2. hg doesn't support this workflow, which may strengthen the need for this PEP. Assuming git's all work is done in a local branch workflow, you could use bookmarks with hg http://lostechies.com/jimmybogard/2010/06/03/translating-my-git-workflow-with-local-branches-to-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-bookmarks http://mercurial.selenic.com/wiki/BookmarksExtension#Usage http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast -- Akira ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
- [ ] Markdown - [ ] ReStructuredText - [ ] Review (why are these out of band?) On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote: Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 12:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. I concur. This article URL:http://mako.cc/writing/hill-free_tools.html makes the arguments well, IMO. 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team […] we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. It’s akin to saying that if we chose to run the PyPI services on a Windows machine that it is somehow makes it less-free even though we could have chosen to run it on a “free” OS and we weren’t doing much, if anything, to tie us to that particular OS. If it makes people feel better we can continue to support the existing mechanisms of contribution, then people can choose between interacting with a “non free” host and “free” tooling. I suspect most people will choose the “non-free” tooling. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
- [ ] Stable URIs - [ ] Commit hashes On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Markdown - [ ] ReStructuredText - [ ] Review (why are these out of band?) On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote: Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 12:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. I concur. This article URL: http://mako.cc/writing/hill-free_tools.html makes the arguments well, IMO. 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team […] we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. It’s akin to saying that if we chose to run the PyPI services on a Windows machine that it is somehow makes it less-free even though we could have chosen to run it on a “free” OS and we weren’t doing much, if anything, to tie us to that particular OS. If it makes people feel better we can continue to support the existing mechanisms of contribution, then people can choose between interacting with a “non free” host and “free” tooling. I suspect most people will choose the “non-free” tooling. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Is there a kalithea celery task to mirror / SYNC with github, for pull requests and/or issues? https://pypi.python.org/pypi/Kallithea/ https://kallithea-scm.org/ https://kallithea-scm.org/repos/kallithea https://bitbucket.org/conservancy/kallithea http://pythonhosted.org//Kallithea http://kallithea.readthedocs.org/en/latest/ http://pypi.python.org/pypi/vcs http://pythonhosted.org//vcs https://github.com/codeinn/vcs On Sun, Nov 30, 2014 at 12:50 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Paste-able links On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Stable URIs - [ ] Commit hashes On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Markdown - [ ] ReStructuredText - [ ] Review (why are these out of band?) On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote: Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 12:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. I concur. This article URL: http://mako.cc/writing/hill-free_tools.html makes the arguments well, IMO. 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team […] we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. It’s akin to saying that if we chose to run the PyPI services on a Windows machine that it is somehow makes it less-free even though we could have chosen to run it on a “free” OS and we weren’t doing much, if anything, to tie us to that particular OS. If it makes people feel better we can continue to support the existing mechanisms of contribution, then people can choose between interacting with a “non free” host and “free” tooling. I suspect most people will choose the “non-free” tooling. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
https://kallithea-scm.org/repos/kallithea/files/tip/setup.py https://github.com/codeinn/vcs/blob/master/setup.py On Sun, Nov 30, 2014 at 1:16 AM, Wes Turner wes.tur...@gmail.com wrote: Is there a kalithea celery task to mirror / SYNC with github, for pull requests and/or issues? https://pypi.python.org/pypi/Kallithea/ https://kallithea-scm.org/ https://kallithea-scm.org/repos/kallithea https://bitbucket.org/conservancy/kallithea http://pythonhosted.org//Kallithea http://kallithea.readthedocs.org/en/latest/ http://pypi.python.org/pypi/vcs http://pythonhosted.org//vcs https://github.com/codeinn/vcs On Sun, Nov 30, 2014 at 12:50 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Paste-able links On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Stable URIs - [ ] Commit hashes On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Markdown - [ ] ReStructuredText - [ ] Review (why are these out of band?) On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote: Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 12:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. I concur. This article URL: http://mako.cc/writing/hill-free_tools.html makes the arguments well, IMO. 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team […] we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. It’s akin to saying that if we chose to run the PyPI services on a Windows machine that it is somehow makes it less-free even though we could have chosen to run it on a “free” OS and we weren’t doing much, if anything, to tie us to that particular OS. If it makes people feel better we can continue to support the existing mechanisms of contribution, then people can choose between interacting with a “non free” host and “free” tooling. I suspect most people will choose the “non-free” tooling. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
- [ ] Paste-able links On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Stable URIs - [ ] Commit hashes On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote: - [ ] Markdown - [ ] ReStructuredText - [ ] Review (why are these out of band?) On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote: Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 12:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: 1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. I concur. This article URL: http://mako.cc/writing/hill-free_tools.html makes the arguments well, IMO. 2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team […] we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. It’s akin to saying that if we chose to run the PyPI services on a Windows machine that it is somehow makes it less-free even though we could have chosen to run it on a “free” OS and we weren’t doing much, if anything, to tie us to that particular OS. If it makes people feel better we can continue to support the existing mechanisms of contribution, then people can choose between interacting with a “non free” host and “free” tooling. I suspect most people will choose the “non-free” tooling. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. Paul I think so yes. I may be wrong, however while 1.9.4 may be the latest downloadable version of git for Windows, there is no downloadable version of the Linux clients at all, they just tell you to go use your package manager which for instance is version 1.7 on Debian. On OS X the latest version is 2.0.1. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com wrote: Donald Stufft donald at stufft.io writes: [words words words] I strongly support this PEP. I'd like to share two pieces of information. Both of these are personal anecdotes: For the past several years, I've been a contributor on two major projects using mercurial, CPython and PyPy. PyPy has a strong culture of in-repo branching, basically all contributors regularly make branches in the main repo for their work, and we're very free in giving people commit rights, so almost everyone working on PyPy in any way has this level of access. This workflow works ok. I don't love it as much as git, but it's fine, it's not an impediment to my work. By contrast, CPython does not have this type of workflow, there are almost no in-tree branches besides the 2.7, 3.4, etc. ones. Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don't generally commit my own work to CPython, even though I have push privledges, because I prefer to *always* get code review on my work. As a result, I use a git mirror of CPython to do all my work, and generate patches from that. The conclusion I draw from this is that hg's workflow is probably fine if you're a committer on the project, or don't ever need to maintain multiple patches concurrently (and thus can just leave everything uncommitted in the repo). However, the hg workflow seems extremely defficient at non-committer contributors. One way to come close to that using hg is to have your own clone that you never push to hg.python.org/cpython (e.g. cloning the Bitbucket clone of cpython or hosting on hg.python.org a personal clone). You can then specify the repo and branch on the issue tracker to generate your patch: https://docs.python.org/devguide/triaging.html#mercurial-repository . After that it's just like any other patch workflow for core devs. It's not quite as nice as maybe using named branches where you can just do a final hg merge/commit to get your changes committed, but if you're not going to commit your branches then you might as well get the automatic patch generation perk in the issue tracker rather than using git (unless there is some other git feature you use that you can't get in hg). The seconds experience I have is that of Django's migration to git and github. For a long time we were on SVN, and we were very resistant to moving to DVCS in general, and github in particular. Multiple times I said that I didn't see how exporting a patch and uploading it to trac was more difficult than sending a pull request. That was very wrong on my part. My primary observation is not about new contributors though, it's actually about the behavior of core developers. Before we were on github, it was fairly rare for core developers to ask for reviews for anything besides *gigantic* patches, we'd mostly just commit stuff to trunk. Since the switch to github, I've seen that core developers are *far* more likely to ask for reviews of their work before merging. Why specifically? Did you have a web UI for reviewing patches previously? Do you have CI set up for patches now and didn't before? What features did you specifically gain from the switch to GitHub that you didn't have before? IOW was it the magic of GitHub or some technical solution that you got as part of the GitHub package and thus could theoretically be replicated on python.org? -Brett ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 2:08 AM, Larry Hastings la...@hastings.org wrote: On 11/29/2014 04:37 PM, Donald Stufft wrote: On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@gmail.com mailto:alex.gay...@gmail.com wrote: Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don’t know how to do this. Instead of collectively scratching your heads, could one of you guys do the research and figure out whether or not hg supports this workflow? One of the following two things must be true: hg supports this workflow (or a reasonable fascimile), which may lessen the need for this PEP. hg doesn't support this workflow, which may strengthen the need for this PEP. Saying I've been using hg for years and I don't know whether it supports this IMPORTANT THING is not a particularly compelling argument. Comments like this make me feel like I didn’t explain myself very well in the PEP. While I do think that supporting this workflow via an extension is worse than supporting it in core, this isn’t why this PEP exists. The current workflow for contributing is painful, for the repositories this is talking about if I’m a non-comitter I have to email patches to a particular closed mailing list and then sit around and wait. The Pull Request based workflow is *massively* better than uploading/emailing patches around. So the question then becomes, if we're going to move to a PR based workflow how do we do it? PEP 474 says that we should install some software that works with Mercurial and supports Pull Requests. Another thread suggested that we should just use to bitbucket whicih also supports Mercurial and use that. This PEP says that git and Github have the popular vote, which is extremely compelling as a feature because: * Popularity is the one thing you can't replicate featurewise. This feature or that you can find a way to work something like it out. * With popularity comes the fact that people will already know the tooling involved and how to use it. This means that a new contributor whom already knows git will spend less time learning our specific toolset and more time being able to meaningfully contribute. * With popularity also comes transferability, If I don't currently know a VCS tool and I learn git (and github) for the sake of these repositories then that knowledge will directly transfer to greater than 60% of the top 100 projects on PyPI. * With popularity also comes an increased amount of people writing about it, asking questions, etc. This means that if I have a problem while using this tool I am more likely to find someone who already had this problem and they are more likely to have found someone to help them solve it than I am with a less popular tool. I'm not sure why people seem to try and focus on the fact that with this extension or that you can make Mercurial replicate git better when that isn't really the major point of the PEP at all. If Mercurial and git were neck in neck in terms of mindshare and bitbucket and Github were as well then this PEP probably wouldn't exist because on a techincal level I think the two tools are probably close enough. However when most of the world is using one tool and you're using another, that does represent a barrier to entry. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 6:18 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: I think there is a big difference here between using a closed source VCS or compiler and using a closed source code host. Namely in that the protocol is defined by git so switching from one host to another is easy. GitHub deliberately encourages proprietary features that create valuable data that cannot be exported — the proprietary GitHub-specific pull requests being a prime example. Once a Pull Request is merged there is little benefit to the PR itself, however if you want the diff you can create a .patch file by appending .diff or .patch to the end of the PR URL. So it is only true to say one can export the data to a different host if one entirely abandons all those features which create GitHub-proprietary data. That’s not true at all. There is an API that allows you to access *all* of the data that is stored there. Allowing you to replicate it to whatever system you wish. If you want to re-write the PEP to be clear you are only talking about the repository hosting of GitHub, and *not* any of its extra features that make it so attractive to use their proprietary service, I'd be interested to see that. On the other hand, if you want to promote those proprietary features as part of the PEP, then it is disingenuous to claim the data can be easily exported to a different host. -- \“Do not enter the lift backwards, and only when lit up.” | `\—elevator, Leipzig | _o__) | Ben Finney ___ 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/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 10:28:50 AM Brett Cannon br...@python.org wrote: Why specifically? Did you have a web UI for reviewing patches previously? Do you have CI set up for patches now and didn't before? What features did you specifically gain from the switch to GitHub that you didn't have before? IOW was it the magic of GitHub or some technical solution that you got as part of the GitHub package and thus could theoretically be replicated on python.org? -Brett Previously someone looking for a review (read: any non-committer) would export a diff from their VCS, upload it as a patch to trac, and then reviewers could leave comments as trac comments. CPython's present process is a clear improvement, insofar as Rietveld allows inlining commenting, but it is otherwise basically the same. By contrast, the Github process does not require a patch author to leave their workflow, they simply git push to update a patch. We now also have CI for PRs, but that's a recent addition. It's not magic, it's a good UX :-) Alex ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote: On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com mailto:alex.gay...@gmail.com wrote: Donald Stufft donald at stufft.io http://stufft.io/ writes: [words words words] I strongly support this PEP. I'd like to share two pieces of information. Both of these are personal anecdotes: For the past several years, I've been a contributor on two major projects using mercurial, CPython and PyPy. PyPy has a strong culture of in-repo branching, basically all contributors regularly make branches in the main repo for their work, and we're very free in giving people commit rights, so almost everyone working on PyPy in any way has this level of access. This workflow works ok. I don't love it as much as git, but it's fine, it's not an impediment to my work. By contrast, CPython does not have this type of workflow, there are almost no in-tree branches besides the 2.7, 3.4, etc. ones. Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don't generally commit my own work to CPython, even though I have push privledges, because I prefer to *always* get code review on my work. As a result, I use a git mirror of CPython to do all my work, and generate patches from that. The conclusion I draw from this is that hg's workflow is probably fine if you're a committer on the project, or don't ever need to maintain multiple patches concurrently (and thus can just leave everything uncommitted in the repo). However, the hg workflow seems extremely defficient at non-committer contributors. One way to come close to that using hg is to have your own clone that you never push to hg.python.org/cpython http://hg.python.org/cpython (e.g. cloning the Bitbucket clone of cpython or hosting on hg.python.org http://hg.python.org/ a personal clone). You can then specify the repo and branch on the issue tracker to generate your patch: https://docs.python.org/devguide/triaging.html#mercurial-repository https://docs.python.org/devguide/triaging.html#mercurial-repository . After that it's just like any other patch workflow for core devs. It's not quite as nice as maybe using named branches where you can just do a final hg merge/commit to get your changes committed, but if you're not going to commit your branches then you might as well get the automatic patch generation perk in the issue tracker rather than using git (unless there is some other git feature you use that you can't get in hg). This doesn’t really work in a Pull Request workflow though I think is the point. Uploading patches is it’s own kind of terrible but yes if you’re just uploading patches you can probably do that. I don’t make branches in Mercurial because i’m afraid I’m going to push a permanent branch to hg.python.org http://hg.python.org/ and screw something up. The seconds experience I have is that of Django's migration to git and github. For a long time we were on SVN, and we were very resistant to moving to DVCS in general, and github in particular. Multiple times I said that I didn't see how exporting a patch and uploading it to trac was more difficult than sending a pull request. That was very wrong on my part. My primary observation is not about new contributors though, it's actually about the behavior of core developers. Before we were on github, it was fairly rare for core developers to ask for reviews for anything besides *gigantic* patches, we'd mostly just commit stuff to trunk. Since the switch to github, I've seen that core developers are *far* more likely to ask for reviews of their work before merging. Why specifically? Did you have a web UI for reviewing patches previously? Do you have CI set up for patches now and didn't before? What features did you specifically gain from the switch to GitHub that you didn't have before? IOW was it the magic of GitHub or some technical solution that you got as part of the GitHub package and thus could theoretically be replicated on python.org http://python.org/? In most of the cases there was some form of a web UI for reviewing patches. I don’t believe there was a CI setup for patches previously and most projects do end up with some sort of CI on Github since Travis makes it particularly easy. Honestly though, I feel like the main reason for it is just that Github’s solution is easy to use, it works with the VCS which is great because that’s what I’m using already, and it’s highly polished. OSS has a long history of having rather poor UX, and poor UX tends to mean that people would rather not use some particular thing unless they *have* to. That is the way I look at Rietveld to be honest. I get frustrated trying to use it so I'd rather just not use it where I feel I can get away with it. It's not really enough to look at a
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com wrote: On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. So I usually choose not to weigh in on discussions like these but there seems to be a lot of misdirection in some of these arguments. To start, I'm generally neutral about this proposal or Nick's proposal that spurred this one. I've found the most frustrating part of contributing to anything involving CPython to be the lack of reviewer time. I have had very small (2-line) patches take months (close to a year in reality) to get through in spite of periodically pinging the appropriate people. Moving to git/GitHub will not alleviate this at all. To be clear, the main reasoning behind Nick's was being able to submit changes without ever having to have a local copy of the repository in question on your machine. Having a complete web workflow for editing and contributing makes the barrier to entry far lower than switching VCS or anything else. BitBucket (apparently, although I've never used this) and GitHub both have this capability and *both* are free-as-in-beer systems. No one as I understand it is proposing that we use the per-distro proprietary interface to these websites. All data can be removed from GitHub using it's API and can generally be converted to another platform. The same goes for BitBucket although it's arguably easier to retrieve issue data from BitBucket than GitHub. That said, *the issue tracker is not covered by these proposals* so this is a moot point. Drop it already. If we're seriously considering moving to git as a DVCS, we should consider the real free-as-in-freedom alternatives that come very close to GitHub and can be improved by us (even though they're not written in Python). One of those is GitLab. We can self-host a GitLab instance easily or we can rely on gitlab.com. GitLab aims to provide a very similar user experience to GitHub and it's slowly approaching feature parity and experience parity. GitLab is also what a lot of people chose to switch to after the incident Steven mentioned, which I don't think is something we should dismiss or ignore. We should refocus the discussion with the following in mind: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process - GitHub has a toxic company culture that we should be aware of before moving to it. They have a couple blog posts about attempting to change it but employees became eerily silent after the incident and have remained so from what I've personally seen. - GitHub may be popular but there are popular FOSS solutions that exist that we can also self-host at something like forge.python.org - bugs.python.org is not covered by any of these proposals - The main benefit this proposal (and the proposal to move to BitBucket) are seeking to achieve is an online editing experience allowing for *anyone with a browser and an account* to contribute. This to me is the only reason I would be +1 for either of these proposals (if we can reach consensus). But that's not just it. As you pointed out, Ian, getting patch submissions committed faster would be a huge improvement over what we have today. GitHub/Bitbucket/whatever could help with this by giving core devs basic CI to know that I patch is sound to some extent as well as push button commits of patches. For me personally, if I knew a simple patch integrated cleanly and passed on at least one buildbot -- when it wasn't a platform-specific fix -- then I could easily push a Commit button and be done with it (although this assumes single branch committing; doing this across branches makes all of this difficult unless we finally resolve our Misc/NEWS conflict issues so that in some instances it can be automated). Instead I have to wait until I have a clone I can push from, download a patch, apply it, run the unit tests myself, do the commit, and then repeat a subset of that to whatever branches make sense. It's a lot of work for which some things could be automated. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014, at 11:45, Donald Stufft wrote: On Nov 30, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote: On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com mailto:alex.gay...@gmail.com wrote: Donald Stufft donald at stufft.io http://stufft.io/ writes: [words words words] I strongly support this PEP. I'd like to share two pieces of information. Both of these are personal anecdotes: For the past several years, I've been a contributor on two major projects using mercurial, CPython and PyPy. PyPy has a strong culture of in-repo branching, basically all contributors regularly make branches in the main repo for their work, and we're very free in giving people commit rights, so almost everyone working on PyPy in any way has this level of access. This workflow works ok. I don't love it as much as git, but it's fine, it's not an impediment to my work. By contrast, CPython does not have this type of workflow, there are almost no in-tree branches besides the 2.7, 3.4, etc. ones. Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don't generally commit my own work to CPython, even though I have push privledges, because I prefer to *always* get code review on my work. As a result, I use a git mirror of CPython to do all my work, and generate patches from that. The conclusion I draw from this is that hg's workflow is probably fine if you're a committer on the project, or don't ever need to maintain multiple patches concurrently (and thus can just leave everything uncommitted in the repo). However, the hg workflow seems extremely defficient at non-committer contributors. One way to come close to that using hg is to have your own clone that you never push to hg.python.org/cpython http://hg.python.org/cpython (e.g. cloning the Bitbucket clone of cpython or hosting on hg.python.org http://hg.python.org/ a personal clone). You can then specify the repo and branch on the issue tracker to generate your patch: https://docs.python.org/devguide/triaging.html#mercurial-repository https://docs.python.org/devguide/triaging.html#mercurial-repository . After that it's just like any other patch workflow for core devs. It's not quite as nice as maybe using named branches where you can just do a final hg merge/commit to get your changes committed, but if you're not going to commit your branches then you might as well get the automatic patch generation perk in the issue tracker rather than using git (unless there is some other git feature you use that you can't get in hg). This doesn’t really work in a Pull Request workflow though I think is the point. Uploading patches is it’s own kind of terrible but yes if you’re just uploading patches you can probably do that. I don’t make branches in Mercurial because i’m afraid I’m going to push a permanent branch to hg.python.org http://hg.python.org/ and screw something up. Don't worry; we have a hook for that. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. It's a good thing that your data isn't locked behind a proprietary door, for now. That's only part of the story. But also, because github is a closed system, there's no guarantee that today's data-freeing APIs will still exist, continue to be functional for practical purposes, remain complete, or stay at parity with new features. Cheers, -Barry [*] And our huge gratitude goes to Paul Boddie for his amazing amount of work on the project. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 11:44 AM, Brett Cannon br...@python.org wrote: On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com mailto:graffatcolmin...@gmail.com wrote: On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net mailto:solip...@pitrou.net wrote: On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com mailto:ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. So I usually choose not to weigh in on discussions like these but there seems to be a lot of misdirection in some of these arguments. To start, I'm generally neutral about this proposal or Nick's proposal that spurred this one. I've found the most frustrating part of contributing to anything involving CPython to be the lack of reviewer time. I have had very small (2-line) patches take months (close to a year in reality) to get through in spite of periodically pinging the appropriate people. Moving to git/GitHub will not alleviate this at all. To be clear, the main reasoning behind Nick's was being able to submit changes without ever having to have a local copy of the repository in question on your machine. Having a complete web workflow for editing and contributing makes the barrier to entry far lower than switching VCS or anything else. BitBucket (apparently, although I've never used this) and GitHub both have this capability and *both* are free-as-in-beer systems. No one as I understand it is proposing that we use the per-distro proprietary interface to these websites. All data can be removed from GitHub using it's API and can generally be converted to another platform. The same goes for BitBucket although it's arguably easier to retrieve issue data from BitBucket than GitHub. That said, *the issue tracker is not covered by these proposals* so this is a moot point. Drop it already. If we're seriously considering moving to git as a DVCS, we should consider the real free-as-in-freedom alternatives that come very close to GitHub and can be improved by us (even though they're not written in Python). One of those is GitLab. We can self-host a GitLab instance easily or we can rely on gitlab.com http://gitlab.com/. GitLab aims to provide a very similar user experience to GitHub and it's slowly approaching feature parity and experience parity. GitLab is also what a lot of people chose to switch to after the incident Steven mentioned, which I don't think is something we should dismiss or ignore. We should refocus the discussion with the following in mind: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process - GitHub has a toxic company culture that we should be aware of before moving to it. They have a couple blog posts about attempting to change it but employees became eerily silent after the incident and have remained so from what I've personally seen. - GitHub may be popular but there are popular FOSS solutions that exist that we can also self-host at something like forge.python.org http://forge.python.org/ - bugs.python.org http://bugs.python.org/ is not covered by any of these proposals - The main benefit this proposal (and the proposal to move to BitBucket) are seeking to achieve is an online editing experience allowing for *anyone with a browser and an account* to contribute. This to me is the only reason I would be +1 for either of these proposals (if we can reach consensus). But that's not just it. As you pointed out, Ian, getting patch submissions committed faster would be a huge improvement over what we have today. GitHub/Bitbucket/whatever could help with this by giving core devs basic CI to know that I patch is sound to some extent as well as push button commits of patches. For me personally, if I knew a simple patch integrated cleanly and passed on at least one buildbot -- when it wasn't a platform-specific fix -- then I could easily push a Commit button and be done with it (although this assumes single branch committing; doing this across branches makes all of this difficult unless we finally resolve our Misc/NEWS conflict issues so that in some instances it can be automated). Instead I have to wait until I have a clone I can push from, download a patch, apply it, run the unit tests myself, do the commit, and then repeat a subset of that to whatever branches make sense. It's a lot of work for which some things could be
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote: On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. I fail to see how this is a reasonable argument to make at all since, as you mentioned, converting between two FLOSS tools can be an amazing amount of work. Realistically the amount of work is going to be predicated on whether or not there is a tool that already handles the conversion for you. Assuming of course that the data is available to you at all. As a particularly relevant example, switching from Mercurial to Git is as easy as installing hg-git, creating a bookmark for master that tracks default, and then pushing to a git repository. It's a good thing that your data isn't locked behind a proprietary door, for now. That's only part of the story. But also, because github is a closed system, there's no guarantee that today's data-freeing APIs will still exist, continue to be functional for practical purposes, remain complete, or stay at parity with new features. This feels like Chicken Little-ing. If Github closed it’s APIs then you could still get at that data by scraping the web interface. However why would Github do that? That would piss off the vast majority of OSS projects who are currently hosted there and is likely to cause a pretty big migration off of Github for fear that Github is going to attempt to lock people onto Github. The popularity of Github *is* Github’s killer feature and doing something that is going to send the vast bulk of your users running for the hills sounds like something that they would have to be particularly stupid to do. Cheers, -Barry [*] And our huge gratitude goes to Paul Boddie for his amazing amount of work on the project. ___ 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/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 12:09 PM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote: On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. I fail to see how this is a reasonable argument to make at all since, as you mentioned, converting between two FLOSS tools can be an amazing amount of work. Realistically the amount of work is going to be predicated on whether or not there is a tool that already handles the conversion for you. Assuming of course that the data is available to you at all. As a particularly relevant example, switching from Mercurial to Git is as easy as installing hg-git, creating a bookmark for master that tracks default, and then pushing to a git repository. When looking for a tool that did this (specifically Github - Gitlab because the two are most similar) I found https://gitlab.com/sigmavirus24/issues-migration/blob/master/migrate.py which happens to be written by Ian. I would guess that he is likely speaking from experience about migrating off of Github to go to Gitlab. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014 11:09 AM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote: On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. I fail to see how this is a reasonable argument to make at all since, as you mentioned, converting between two FLOSS tools can be an amazing amount of work. Realistically the amount of work is going to be predicated on whether or not there is a tool that already handles the conversion for you. Assuming of course that the data is available to you at all. As a particularly relevant example, switching from Mercurial to Git is as easy as installing hg-git, creating a bookmark for master that tracks default, and then pushing to a git repository. It's a good thing that your data isn't locked behind a proprietary door, for now. That's only part of the story. But also, because github is a closed system, there's no guarantee that today's data-freeing APIs will still exist, continue to be functional for practical purposes, remain complete, or stay at parity with new features. This feels like Chicken Little-ing. If Github closed it’s APIs then you could still get at that data by scraping the web interface. However why would Github do that? That would piss off the vast majority of OSS projects who are currently hosted there and is likely to cause a pretty big migration off of Github for fear that Github is going to attempt to lock people onto Github. The popularity of Github *is* Github’s killer feature and doing something that is going to send the vast bulk of your users running for the hills sounds like something that they would have to be particularly stupid to do. Cheers, -Barry [*] And our huge gratitude goes to Paul Boddie for his amazing amount of work on the project. ___ 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/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA I tend to agree with Donald that it's highly unlikely for GitHub to close off their APIs but Barry is right that it isn't impossible. That can be mitigated by regularly scheduling a back-up of that data using the tools we have now so that the sky doesn't appear to be falling if the worst case does occur. I also tend to disagree with Barry that it will be extraordinarily difficult because I have migrated issues and pull requests off of GitHub and was able to automate the entirety of it reliably with python. Admittedly, I'm very familiar with GitHub's API as the author of github3.py so for me this is a trivial task. I would also be willing to help set up migrations and back ups if we decide to use GitHub. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 11:30 AM, Donald Stufft don...@stufft.io wrote: Comments like this make me feel like I didn’t explain myself very well in the PEP. It’s been pointed out to me that Mercurial bookmarks have been core since 1.8 and since I felt like the technical arguments were really secondary to the social arguments I’ve gone ahead and removed that section from the PEP. I’ve also added the read only Mercurial repository on hg.python.org http://hg.python.org/ See changes at https://hg.python.org/peps/rev/d31fe28e2766 --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/29/2014 10:14 PM, Demian Brecht wrote: On Sat, Nov 29, 2014 at 3:27 PM, Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: As promised in the Move selected documentation repos to PSF BitBucket account? thread I've written up a PEP for moving selected repositories from hg.python.org http://hg.python.org to Github. FWIW, I'm a pretty solid -1 to this PEP. Agreed. -1 for the same reasons (plus most of Nick's). -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 11:17, Chris Angelico ros...@gmail.com wrote: On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan ncogh...@gmail.com wrote: On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote: Python is already using quite a bit of non-free software in its ecosystem. The Windows builds of CPython are made with Microsoft's compiler, and the recent discussion about shifting to Cygwin or MinGW basically boiled down to but it ought to be free software, and that was considered not a sufficiently strong argument. In each case, the decision has impact on other people (using MSVC for the official python.org installers means extension writers need to use MSVC too; and using GitHub means that contributors are strongly encouraged, possibly required, to use GitHub); so why is it acceptable to use a non-free compiler, but not acceptable to use a non-free host? Relying on non-free software to support users of a non-free platform is rather different from *requiring* the use of non-free software to participate in core Python community design processes. But what non-free software is required to use the community design processes? The GitHub client is entirely optional; I don't use it, I just use git itself. Using a free client to access a proprietary server isn't the same as using non-free software. Also keep in mind that unless you are using a very esoteric hardware setup and dedicated leased lines that you purchased yourself, you are likely to be using copyrighted, patented, proprietary software at a number of levels: the microcode implementation in your CPU the firmware in your GPU the firmware in your network card the boot code (e.g.: BIOS or EFI implementation) of your motherboard the firmware in your router or the firmware in your cable or DSL modem, if you thought to get a free router with OpenWRT or something in it the firmware in your ISP's router the firmware in the backbone's routers the firmware in the PSF's ISP's routers Does this sound like ridiculous nitpicking? Of course it does! If you refused to use all that stuff you just wouldn't be able to access the internet at all, regardless of your personal choices. Most layers of this stack are _less_ constrained to open standards and open data access than Github, and can require layers and layers of additional proprietary software or reverse engineering (ask anyone who has tried to play a video game on a Linux computer what the experience is like without gobs of proprietary blobs from nvidia or ATI). And as the story of BitKeeper shows, if a proprietary platform decides to do something bad, if the cost of migration is within your means, you can just leave. This is far more true of Github than Bitkeeper - Linux had to create a totally new VCS to migrate off of that, we just have to install Trac or Roundup or something again. (Which, as per the presently-proposed PEP, we don't even have to install them again, just change some configuration to put a few repositories back.) The monoculture about Github concerns me. I also have concerns about the long-term consequences of not having an all-free-software stack. But focusing on avoiding services like Github at this point in history is just a gigantic waste of time; it's resolving dependencies in the wrong order. The only reason to avoid Github is ideological purity, and even then it's not even purity because you still have to accept this other ideological contamination. Except, what about other ideological concepts that are important to the Python core developers, like equitable representation for women and minorities, and compassionate and polite interactions within the community? Clearly we can't require the use of Linux. If we treat these ideals as an equivalent priority as free software (even if we ignore the invisible dependencies like the list I just made above), then there is literally no software left that we can use to develop Python. Linux kernel and GNU low-level user-land development are a perpetual cesspit, and their leaders serve as a continuous embarrassment to our community. And speaking of equitable representation, one proven technique we have learned for dealing with that problem is making it for newcomers of all stripes to access the community. Like it or not, Github's popularity means that it's a place where most newcomers to programming are learning to use version control and bug tracking. This is a network effect that can have a real impact on people's lives. Requiring newcomers to learn our weird technology religion before they can contribute creates a real barrier to entry, which in turn makes our community more insular and homogenous. Some days you get the Git, and some days the Github gets you. The sooner we, as a community and a culture, can accept this and move on, the more time will be available to actually build replacements for these things. -glyph
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
I don't feel it's my job to accept or reject this PEP, but I do have an opinion. The scope of the PSF organization is far beyond just the Python language -- it includes the Python developer community, the Python user community, 3rd party Python packages and their communities (even if some have created their own organizations). But I think that it is scope creep to try and be pure in our tooling or workflows. Python has a long history (all the way back to my choice of a MIT-style license for the first release) of mixing free and non-free uses and tools -- for example on Windows we consciously chose to align ourselves with the platform tooling rather than with the (minority) free tools available, Python has been ported to many commercial platforms, and I've always encouraged use of Python in closed-source situations. I bring this up to emphasize that (unlike GNU software and the FSF) Python has no additional hidden agenda of bringing freedom to all software. At least that's how I feel about it -- clearly some of the most vocal contributors to this thread feel differently. Now some entirely practical points. - I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests. - I am not worried about lock in. The most important stuff is copied in the local git repos of hundreds of core devs and thousands of others. Pull requests are by nature short-lived -- and if you really want a history of the back-and-forth that led to the eventual set of diffs that was integrated, you could subscribe a mailing list to it to archive it. I'm sure there's a way to back up the issue tracker too. Finally. And this may actually be the most important point. Python people should be doing stuff that makes Python better (both taken in the most inclusive way possible). For stuff that's not unique to Python but can be used by many other open-source projects, such as compilers, DVCS tools, or mailing lists, we should not be wasting our precious time on building and maintaining our own tools or administering the servers on which they run. And historically we've not done a great job on maintenance and administration. Of course it's fun to make tools in Python, and to see them used beyond the Python world. But that's an entirely different argument from what I hear. -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 30 November 2014 at 16:08, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. Paul I think so yes. I may be wrong, however while 1.9.4 may be the latest downloadable version of git for Windows, there is no downloadable version of the Linux clients at all, they just tell you to go use your package manager which for instance is version 1.7 on Debian. On OS X the latest version is 2.0.1. OTOH, presumably you can build your own copy of git from source on Linux/OSX. I haven't tried this on Windows but it looks pretty difficult (you start by downloading the msysgit development environment and go from there). Also, if it's easy to produce binaries for 2.2.0 on Windows, why haven't the msysgit project (still an external project, to an extent, AFAICT) done so? Paul ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Can this discussion be split off into a separate discussion. It's tangential to the PEP and clearly not actively progressing so it doesn't seem productive. I don't care where it's taken, but I don't think this belongs here. Speculation on the actions of the msysgit project are not fair talk for this PEP. On Sun, Nov 30, 2014 at 12:14 PM, Paul Moore p.f.mo...@gmail.com wrote: On 30 November 2014 at 16:08, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. Paul I think so yes. I may be wrong, however while 1.9.4 may be the latest downloadable version of git for Windows, there is no downloadable version of the Linux clients at all, they just tell you to go use your package manager which for instance is version 1.7 on Debian. On OS X the latest version is 2.0.1. OTOH, presumably you can build your own copy of git from source on Linux/OSX. I haven't tried this on Windows but it looks pretty difficult (you start by downloading the msysgit development environment and go from there). Also, if it's easy to produce binaries for 2.2.0 on Windows, why haven't the msysgit project (still an external project, to an extent, AFAICT) done so? Paul ___ 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/graffatcolmingov%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 1:05 PM, Guido van Rossum gu...@python.org wrote: I don't feel it's my job to accept or reject this PEP, but I do have an opinion. So here’s a question. If it’s not your job to accept or reject this PEP, whose is it? This is probably an issue we’re never going to get actual consensus on so unless there is an arbitrator of who gets to decide I feel it’s probably a waste of my time to try and convince absolutely *everyone*. The scope of the PSF organization is far beyond just the Python language -- it includes the Python developer community, the Python user community, 3rd party Python packages and their communities (even if some have created their own organizations). But I think that it is scope creep to try and be pure in our tooling or workflows. Python has a long history (all the way back to my choice of a MIT-style license for the first release) of mixing free and non-free uses and tools -- for example on Windows we consciously chose to align ourselves with the platform tooling rather than with the (minority) free tools available, Python has been ported to many commercial platforms, and I've always encouraged use of Python in closed-source situations. I bring this up to emphasize that (unlike GNU software and the FSF) Python has no additional hidden agenda of bringing freedom to all software. At least that's how I feel about it -- clearly some of the most vocal contributors to this thread feel differently. Yes, this is how I feel about Python too, that it’s the pragmatic language/community not the purist language/community. Now some entirely practical points. - I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests. - I am not worried about lock in. The most important stuff is copied in the local git repos of hundreds of core devs and thousands of others. Pull requests are by nature short-lived -- and if you really want a history of the back-and-forth that led to the eventual set of diffs that was integrated, you could subscribe a mailing list to it to archive it. I'm sure there's a way to back up the issue tracker too. Finally. And this may actually be the most important point. Python people should be doing stuff that makes Python better (both taken in the most inclusive way possible). For stuff that's not unique to Python but can be used by many other open-source projects, such as compilers, DVCS tools, or mailing lists, we should not be wasting our precious time on building and maintaining our own tools or administering the servers on which they run. And historically we've not done a great job on maintenance and administration. Of course it's fun to make tools in Python, and to see them used beyond the Python world. But that's an entirely different argument from what I hear. -- --Guido van Rossum (python.org/~guido http://python.org/~guido) --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 12:00:20 PM Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 11:44 AM, Brett Cannon br...@python.org wrote: On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com wrote: On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. So I usually choose not to weigh in on discussions like these but there seems to be a lot of misdirection in some of these arguments. To start, I'm generally neutral about this proposal or Nick's proposal that spurred this one. I've found the most frustrating part of contributing to anything involving CPython to be the lack of reviewer time. I have had very small (2-line) patches take months (close to a year in reality) to get through in spite of periodically pinging the appropriate people. Moving to git/GitHub will not alleviate this at all. To be clear, the main reasoning behind Nick's was being able to submit changes without ever having to have a local copy of the repository in question on your machine. Having a complete web workflow for editing and contributing makes the barrier to entry far lower than switching VCS or anything else. BitBucket (apparently, although I've never used this) and GitHub both have this capability and *both* are free-as-in-beer systems. No one as I understand it is proposing that we use the per-distro proprietary interface to these websites. All data can be removed from GitHub using it's API and can generally be converted to another platform. The same goes for BitBucket although it's arguably easier to retrieve issue data from BitBucket than GitHub. That said, *the issue tracker is not covered by these proposals* so this is a moot point. Drop it already. If we're seriously considering moving to git as a DVCS, we should consider the real free-as-in-freedom alternatives that come very close to GitHub and can be improved by us (even though they're not written in Python). One of those is GitLab. We can self-host a GitLab instance easily or we can rely on gitlab.com. GitLab aims to provide a very similar user experience to GitHub and it's slowly approaching feature parity and experience parity. GitLab is also what a lot of people chose to switch to after the incident Steven mentioned, which I don't think is something we should dismiss or ignore. We should refocus the discussion with the following in mind: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process - GitHub has a toxic company culture that we should be aware of before moving to it. They have a couple blog posts about attempting to change it but employees became eerily silent after the incident and have remained so from what I've personally seen. - GitHub may be popular but there are popular FOSS solutions that exist that we can also self-host at something like forge.python.org - bugs.python.org is not covered by any of these proposals - The main benefit this proposal (and the proposal to move to BitBucket) are seeking to achieve is an online editing experience allowing for *anyone with a browser and an account* to contribute. This to me is the only reason I would be +1 for either of these proposals (if we can reach consensus). But that's not just it. As you pointed out, Ian, getting patch submissions committed faster would be a huge improvement over what we have today. GitHub/Bitbucket/whatever could help with this by giving core devs basic CI to know that I patch is sound to some extent as well as push button commits of patches. For me personally, if I knew a simple patch integrated cleanly and passed on at least one buildbot -- when it wasn't a platform-specific fix -- then I could easily push a Commit button and be done with it (although this assumes single branch committing; doing this across branches makes all of this difficult unless we finally resolve our Misc/NEWS conflict issues so that in some instances it can be automated). Instead I have to wait until I have a clone I can push from, download a patch, apply it, run the unit tests myself, do the commit, and then repeat a subset of that to whatever branches make sense. It's a lot of work for which some things could be automated. Well there’s two sides to the contribution process. There’s making things better/easier for people who
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org wrote: All very true, but if we can't improve both sides then we are simply going to end up with even more patches that we take a while to get around to. I want to end up with a solution that advances the situation for *both* committers and non-committers and I feel like that is being lost in the discussion somewhat. As the person who pushed for a migration to DVCS for non-committers I totally support improving the workflow for non-committers, but not at the cost of ignoring the latter half of the contribution workflow of committers which is a chronic problem. As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. But moving devinabox where there is going to be a code checkout in order to execute code for testing, etc. will be an issue. So I guess my view is +0 for doc-only repos on GitHub as long as we make it clear we are doing it with the expectation that people will do everything through the web UI and never have to know git. But I can't advocate moving code over without moving ALL repos over to git -- hosting location doesn't matter to me -- to prevent having to know both DVCSs in order to do coding work related to Python; the cpython repo shouldn't become this vaunted repo that is special and so it's in hg long-term but everything else is on git. So a goal of mine here is to sort of use these as a bit of a test bed. Moving CPython itself is a big and drastic change with a lot of implications, but moving the “support” repositories is not nearly as much, especially with a read only mirror on hg.python.org http://hg.python.org/ which would allow things like the PEP rendering on www.python.org http://www.python.org/ to stay the same if we wanted to. My hope was that we’d try this out, see how it works out, and if it seems to be a good thing, then at a later time we can either look at moving CPython itself or decide if it makes sense to do something different. Maybe this should be spelled out in the PEP? I’ve seen a few people say they were -1 because they didn’t want to split between hg on the CPython side and git on the supporting repos side. I’m not sure you can really get away from that because we’re *already* in that situation, things like the docs building script is a Git repo on Github, the python infrastructure itself is a git repo on Github, the new python.org http://python.org/ website is a git repo on Github, the future PyPI is a git repo on GitHub. IOW I’m not sure what the best way forward is. I think moving to these tools for *all* repos is likely to be in the best interests of making things better for both sides of that coin however I didn’t want to go wholesale and try and make everything switch at all at once. If you think it makes sense to drop devinabox and make the dividing line between Code and not code (although I’d argue that line is already crossed with other code things already being on github) that’s fine with me. Or I can expand the scope if people think that makes more sense in the PEP too. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 2:28 PM, Ethan Furman et...@stoneleaf.us wrote: On 11/30/2014 10:05 AM, Guido van Rossum wrote: Python has a long history (all the way back to my choice of a MIT-style license for the first release) of mixing free and non-free uses and tools -- for example on Windows we consciously chose to align ourselves with the platform tooling rather than with the (minority) free tools available, Python has been ported to many commercial platforms, and I've always encouraged use of Python in closed-source situations. For this I am grateful, and agree with. Finally. And this may actually be the most important point. Python people should be doing stuff that makes Python better (both taken in the most inclusive way possible). For stuff that's not unique to Python but can be used by many other open-source projects, such as compilers, DVCS tools, or mailing lists, we should not be wasting our precious time on building and maintaining our own tools or administering the servers on which they run. And historically we've not done a great job on maintenance and administration. My issues with GitHub range from selfish to philosophical: - (selfish) I don't want to learn git Note: That you don’t actually have to learn git, you can clone a git repository with Mercurial using hg-git and continue to use Mercurial locally. The same of course can be said for the *other* way, but I’d argue that putting the burden of using things like hg-git or git-remote-hg on the less popular tool is a better overall decision. - (practical) from what I hear git can have issues with losing history -- in a project that has many volunteer and part-time developers, using a tool that can munge your data just doesn't seem very wise I have never heard of git losing history. Git goes out of it’s way not to lose things. Even unreferences commits don’t go away for months unless you purposely prune them. I’d personally call this FUD unless there’s some citation here. - (practical) supporting git and hg means learning two different workflows As I mentioned in my other email, we’re already supporting two different tools, and it’s a hope of mine to use this as a sort of testbed to moving the other repositories as well. - (philosophical) in a commercial world we vote with our dollars (don't like how a company behaves? don't buy their product); in an OSS world we vote by whose services/software we use; I don't want to support, or appear to support, a company that is abusive and sexist towards its employees: it is not what the PSF supports, and it's definitely not what I support. I’m assuming this is about Github. I’ll say that Github has, at least publicly, made steps towards doing better than they had previously there. I’m not a Github employee so I can’t speak towards that. It almost feels like there is some amount of co-opting this incident as a shield to hide behind. Most people who make this statement are more than happy to continue to use Linux for example, even though Linus is well documented being extremely abusive towards people and has more or less said that he’s never going to change that. I also think it’s hard to look at a company like bitbucket, for example, and say they are *better* than Github just because they didn’t have a public and inflammatory event. Attempting to reduce the cognitive burden for contributing and aligning ourselves with the most popular tools allows us to take advantage of the network effects of these tools popularity. This can be the difference between someone with limited amount of time being able to contribute or not, which can make real inroads towards making it easier for under privileged people to contribute much more than refusing to use a product of one group of people over another just because the other group hasn’t had a public and inflammatory event. Not everyone is suited to demonstrate in the streets, but it shouldn't be that hard to not use a company with acknowledged bad practices. -- ~Ethan~ ___ 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/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 1, 2014 at 6:28 AM, Ethan Furman et...@stoneleaf.us wrote: My issues with GitHub range from selfish to philosophical: - (selfish) I don't want to learn git This ties in directly with the popularity argument. How many people are there who know hg and don't know git? How many who know git and don't know hg? So while this is a git issue for you, it's going to be a Mercurial issue for a lot more people. (And even people like me who kinda know both are going to spend a lot more time with git than with hg, on average. My knowledge of git is fairly advanced - I use git hooks, have scripts that manage things for me, can repair a repository that's seen some mess in it, etc - but my Mercurial knowledge is basic - I can clone and pull, not even sure I can push as I have literally never done so, and I basically turn to a dev guide to figure out how to make a patch in the appropriate way.) - (practical) from what I hear git can have issues with losing history -- in a project that has many volunteer and part-time developers, using a tool that can munge your data just doesn't seem very wise It is possible to rewrite history in git, but - assuming you're not going to go to the ridiculous extent of SHA-1 cracking - it'll always be done by creating a new stream of commits, and git is very careful about confirming that you want to do this sort of thing. When you have a central server, you can simply configure it to reject any non-fast-forward pushes. (I'm not sure how to set receive.denyNonFastForwards on GitHub, but it's likely to be possible. In any case, you can always have an authoritative clone on python.org somewhere which mandates this kind of thing.) The git philosophy is: Your repository is yours. What you do with it is up to you. If that means rewriting history, git will confirm with you that you really want to do that, and then go right ahead and do what you ask. But then if your repo is a clone of someone else's, well, that someone else controls the other repo, so you might well not be allowed to merge changes in. - (practical) supporting git and hg means learning two different workflows Already a problem for a lot of people. Unless CPython is the only project you ever contribute to, chances are you're going to meet git somewhere. If CPython used some mindblowingly brilliant but utterly unheard-of DVCS, sure it might be possible for core devs to avoid using any of the popular systems, but nobody else could. Personally, and somewhat selfishly, I would love to see the PEPs repo move to GitHub. For the two PEPs that I wrote, I had to juggle my own personal PEP draft repo and the central Mercurial peps repo; making sure changes got deployed from one to the other was basically a manual job, without any tool support. If I could send PRs against a clone of the peps repo, I would work that way instead of creating a dedicated repo at all (at least until such time as I need other files; the PEP 463 repo grew a few other bits and bobs, but they could just as easily have been in an ancillary repo without the PEP text in it). There'll be easily as many people who selfishly want git as selfishly want hg :) ChrisA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org wrote: All very true, but if we can't improve both sides then we are simply going to end up with even more patches that we take a while to get around to. I want to end up with a solution that advances the situation for *both* committers and non-committers and I feel like that is being lost in the discussion somewhat. As the person who pushed for a migration to DVCS for non-committers I totally support improving the workflow for non-committers, but not at the cost of ignoring the latter half of the contribution workflow of committers which is a chronic problem. As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. But moving devinabox where there is going to be a code checkout in order to execute code for testing, etc. will be an issue. So I guess my view is +0 for doc-only repos on GitHub as long as we make it clear we are doing it with the expectation that people will do everything through the web UI and never have to know git. But I can't advocate moving code over without moving ALL repos over to git -- hosting location doesn't matter to me -- to prevent having to know both DVCSs in order to do coding work related to Python; the cpython repo shouldn't become this vaunted repo that is special and so it's in hg long-term but everything else is on git. So a goal of mine here is to sort of use these as a bit of a test bed. Moving CPython itself is a big and drastic change with a lot of implications, but moving the “support” repositories is not nearly as much, especially with a read only mirror on hg.python.org which would allow things like the PEP rendering on www.python.org to stay the same if we wanted to. My hope was that we’d try this out, see how it works out, and if it seems to be a good thing, then at a later time we can either look at moving CPython itself or decide if it makes sense to do something different. Maybe this should be spelled out in the PEP? I’ve seen a few people say they were -1 because they didn’t want to split between hg on the CPython side and git on the supporting repos side. I’m not sure you can really get away from that because we’re *already* in that situation, things like the docs building script is a Git repo on Github, the python infrastructure itself is a git repo on Github, the new python.org website is a git repo on Github, the future PyPI is a git repo on GitHub. That doesn't bother as that is support infrastructure around CPython but in no way directly tied to CPython releases. But devinabox, for instance, is specifically for helping people contribute to CPython, so asking people to use devinabox in git but then work in hg for some repos and git in others that devinabox checks out is just asking for trouble (e.g. devinabox checks out the peps, devguide, and cpython repos). IOW I’m not sure what the best way forward is. I think moving to these tools for *all* repos is likely to be in the best interests of making things better for both sides of that coin however I didn’t want to go wholesale and try and make everything switch at all at once. If you think it makes sense to drop devinabox and make the dividing line between Code and not code (although I’d argue that line is already crossed with other code things already being on github) that’s fine with me. Or I can expand the scope if people think that makes more sense in the PEP too. Depends what other people think, but for me it's we are going to move to git long-term and we are starting an experiment with docs on GitHub to see if that impacts contributions and committer maintenance at least for docs, maybe for code eventually. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 11:56 AM, Donald Stufft wrote: On Nov 30, 2014, at 2:28 PM, Ethan Furman et...@stoneleaf.us wrote: My issues with GitHub range from selfish to philosophical: - (selfish) I don't want to learn git Note: That you don’t actually have to learn git, you can clone a git repository with Mercurial using hg-git and continue to use Mercurial locally. The same of course can be said for the *other* way, but I’d argue that putting the burden of using things like hg-git or git-remote-hg on the less popular tool is a better overall decision. Fair enough. - (practical) from what I hear git can have issues with losing history -- in a project that has many volunteer and part-time developers, using a tool that can munge your data just doesn't seem very wise I have never heard of git losing history. Git goes out of it’s way not to lose things. Even unreferences commits don’t go away for months unless you purposely prune them. I’d personally call this FUD unless there’s some citation here. Okay. - (practical) supporting git and hg means learning two different workflows As I mentioned in my other email, we’re already supporting two different tools, and it’s a hope of mine to use this as a sort of testbed to moving the other repositories as well. That should be in the PEP then. - (philosophical) in a commercial world we vote with our dollars (don't like how a company behaves? don't buy their product); in an OSS world we vote by whose services/software we use; I don't want to support, or appear to support, a company that is abusive and sexist towards its employees: it is not what the PSF supports, and it's definitely not what I support. I’m assuming this is about Github. Yes. I’ll say that Github has, at least publicly, made steps towards doing better than they had previously there. I’m not a Github employee so I can’t speak towards that. It almost feels like there is some amount of co-opting this incident as a shield to hide behind. Most people who make this statement are more than happy to continue to use Linux for example, even though Linus is well documented being extremely abusive towards people and has more or less said that he’s never going to change that. Linux is not my choice. ;) Linus is also one person, not an entire company. I also think it’s hard to look at a company like bitbucket, for example, and say they are *better* than Github just because they didn’t have a public and inflammatory event. In cases like this it's not better but willing to work with. BitBucket might be as hostile as GitHub, only someone who has worked for both could really know. [...] than refusing to use a product of one group of people over another just because the other group hasn’t had a public and inflammatory event. We can only make decisions on information we have; pretending we don't have it, or that some other company /could/ be the same, is hiding our heads in the sand. If git is the wave of the future, there are other git hosts besides GitHub. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, 30 Nov 2014 19:19:50 + Brett Cannon br...@python.org wrote: As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. Web-based text editors are a poor UI so, while it *can* be done over the Web, it's not really a good thing to promote (unless we're talking mini-edits such as fixing typos). Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, 30 Nov 2014 10:05:01 -0800 Guido van Rossum gu...@python.org wrote: I bring this up to emphasize that (unlike GNU software and the FSF) Python has no additional hidden agenda of bringing freedom to all software. As far as GNU and the FSF are concerned, I don't think the agenda is hidden at all ;-) Now some entirely practical points. - I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests. Are you sure that those contributors wouldn't want to use Bitbucket - or another hg-based hosting service? A PEP contributor is someone who is likely to contribute CPython code as well - so they would have to know hg. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 4:05 PM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 30 Nov 2014 10:05:01 -0800 Guido van Rossum gu...@python.org wrote: I bring this up to emphasize that (unlike GNU software and the FSF) Python has no additional hidden agenda of bringing freedom to all software. As far as GNU and the FSF are concerned, I don't think the agenda is hidden at all ;-) Now some entirely practical points. - I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests. Are you sure that those contributors wouldn't want to use Bitbucket - or another hg-based hosting service? A PEP contributor is someone who is likely to contribute CPython code as well - so they would have to know hg. Speaking as someone who has written a number of PEPS, plans to write a number more, and also has commit bit on hg.python.org and is maintaining code in CPython. I would greatly prefer using Github for PEPs than I would any hg hosting service I’ve seen to date. I can’t obviously speak for every single committer, however Guido also stated that through his work in committing patches of incoming PEPs he’s seen that a lot of the PEPs are being written on Github using git. I think it’s fair to say that those people would prefer PRs on Github over using Bitbucket as well since they were choosing Github over Bitbucket when there was no incentive to do so. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 3:26 PM, Brett Cannon br...@python.org wrote: On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org mailto:br...@python.org wrote: All very true, but if we can't improve both sides then we are simply going to end up with even more patches that we take a while to get around to. I want to end up with a solution that advances the situation for *both* committers and non-committers and I feel like that is being lost in the discussion somewhat. As the person who pushed for a migration to DVCS for non-committers I totally support improving the workflow for non-committers, but not at the cost of ignoring the latter half of the contribution workflow of committers which is a chronic problem. As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. But moving devinabox where there is going to be a code checkout in order to execute code for testing, etc. will be an issue. So I guess my view is +0 for doc-only repos on GitHub as long as we make it clear we are doing it with the expectation that people will do everything through the web UI and never have to know git. But I can't advocate moving code over without moving ALL repos over to git -- hosting location doesn't matter to me -- to prevent having to know both DVCSs in order to do coding work related to Python; the cpython repo shouldn't become this vaunted repo that is special and so it's in hg long-term but everything else is on git. So a goal of mine here is to sort of use these as a bit of a test bed. Moving CPython itself is a big and drastic change with a lot of implications, but moving the “support” repositories is not nearly as much, especially with a read only mirror on hg.python.org http://hg.python.org/ which would allow things like the PEP rendering on www.python.org http://www.python.org/ to stay the same if we wanted to. My hope was that we’d try this out, see how it works out, and if it seems to be a good thing, then at a later time we can either look at moving CPython itself or decide if it makes sense to do something different. Maybe this should be spelled out in the PEP? I’ve seen a few people say they were -1 because they didn’t want to split between hg on the CPython side and git on the supporting repos side. I’m not sure you can really get away from that because we’re *already* in that situation, things like the docs building script is a Git repo on Github, the python infrastructure itself is a git repo on Github, the new python.org http://python.org/ website is a git repo on Github, the future PyPI is a git repo on GitHub. That doesn't bother as that is support infrastructure around CPython but in no way directly tied to CPython releases. But devinabox, for instance, is specifically for helping people contribute to CPython, so asking people to use devinabox in git but then work in hg for some repos and git in others that devinabox checks out is just asking for trouble (e.g. devinabox checks out the peps, devguide, and cpython repos). I’m not sure what you’re proposing here. If devinabox checks out peps, devguide, and cpython aren’t they going to have to use git and hg both unless we move all of those repositories together? Beyond just the tools the status quo of those is that if you do make a change you have different ways to submit a contribution depending on which repository it is. IOW I’m not sure what the best way forward is. I think moving to these tools for *all* repos is likely to be in the best interests of making things better for both sides of that coin however I didn’t want to go wholesale and try and make everything switch at all at once. If you think it makes sense to drop devinabox and make the dividing line between Code and not code (although I’d argue that line is already crossed with other code things already being on github) that’s fine with me. Or I can expand the scope if people think that makes more sense in the PEP too. Depends what other people think, but for me it's we are going to move to git long-term and we are starting an experiment with docs on GitHub to see if that impacts contributions and committer maintenance at least for docs, maybe for code eventually”. What do you mean by “docs”, is that the devguide and PEPs repository? Here’s another idea for an
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 2:33 PM, Donald Stufft wrote: So a goal of mine here is to sort of use these as a bit of a test bed. Moving CPython itself is a big and drastic change with a lot of implications, but moving the “support” repositories is not nearly as much, especially with a read only mirror on hg.python.org http://hg.python.org which would allow things like the PEP rendering on www.python.org http://www.python.org to stay the same if we wanted to. My hope was that we’d try this out, see how it works out, and if it seems to be a good thing, then at a later time we can either look at moving CPython itself or decide if it makes sense to do something different. Maybe this should be spelled out in the PEP? I’ve seen a few people say they were -1 because they didn’t want to split between hg on the CPython side and git on the supporting repos side. Being only recently somewhat comfortable with hg, I do not really want to have to learn git at this time. I’m not sure you can really get away from that because we’re *already* in that situation, things like the docs building script is a Git repo on Github, As long as I can do test doc builds with the scripts in /Docs, this does not matter to me. If the people who work with the site doc build script want it in git on Github, fine. the python infrastructure itself is a git repo on Github, Since I am not sure what you mean, its location does not matter to me. the new python.org http://python.org website is a git repo on Github, the future PyPI is a git repo on GitHub. Since I do not commit to either, ditto. As far as I am concerned, the people involved with specialized repositories may as well have their preference. This includes devinabox. I have made a few commits to the PEP repository, but only to the one I co-authored, 434. Using the web form might make it easier to suggest changes to other peoples' PEPs. IOW I’m not sure what the best way forward is. I think moving to these tools for *all* repos is likely to be in the best interests of making things better for both sides of that coin however I didn’t want to go wholesale and try and make everything switch at all at once. I agree with others that the current bottleneck is disposing of patches, especially those from non-core developers, not getting more patches to considier. I am quite sure that if we significantly reduce the current backlog of 4600 issues and more expeditiously handles the contributions we do get, will will get more. More than one person has said that they are disinclined to submit patches when they have multiple patches on the tracker already. So I think the focus should be on making better use of developer time and having more of it. -- 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 10:55 AM, Barry Warsaw ba...@python.org wrote: On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. The GitHub API is currently at Version 3. These may be useful references for the PEP: https://developer.github.com/v3/ https://developer.github.com/libraries/ https://github.com/jaxbot/github-issues.vim (:Gissues) https://developer.github.com/webhooks/ There are integrations for many platforms here: https://zapier.com/developer/documentation/ https://zapier.com/zapbook/apps/#sort=popularfilter=developer-tools Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. It's a good thing that your data isn't locked behind a proprietary door, for now. That's only part of the story. But also, because github is a closed system, there's no guarantee that today's data-freeing APIs will still exist, continue to be functional for practical purposes, remain complete, or stay at parity with new features. Cheers, -Barry [*] And our huge gratitude goes to Paul Boddie for his amazing amount of work on the project. ___ 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/wes.turner%40gmail.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 1:05 PM, Guido van Rossum wrote: I don't feel it's my job to accept or reject this PEP, but I do have an opinion. ... - I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests. The scope of the PEP is still apparently somewhat fluid. I said elsewhere that I think the principal maintainers of a specialized single-branch repository should have the principal say in where it lives. So I think you should be the one to decide on a PEP limited to moving the PEP repository. My understanding is that if the peps were moved to github, then I would be able to suggest changes via an online web form that would generate a pull request from edited text. If so, I would say go ahead and move them and see how it goes. To me, the multibranch CPython repository is a very different issue. I think it should stay where it is for now, especially with 2.7 support extended. I think for this we should better focus on better use of developer time and getting more developers active. -- 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft don...@stufft.io writes: I have never heard of git losing history. In my experience talking with Git users about this problem, that depends on a very narrow definition of “losing history”. Git encourages re-writing, and thereby losing prior versions of, the history of a branch. The commit information remains, but the history of how they link together is lost. That is a loss of information, which is not the case in the absence of such history re-writing. Git users differ in whether they consider that information loss important; but it is, objectively, losing history information. So Ethan's impression is correct on this point. -- \ “If you see an animal and you can't tell if it's a skunk or a | `\ cat, here's a good saying to help: ‘Black and white, stinks all | _o__) right. Tabby-colored, likes a fella.’” —Jack Handey | Ben Finney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 7:17 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: I have never heard of git losing history. In my experience talking with Git users about this problem, that depends on a very narrow definition of “losing history”. Git encourages re-writing, and thereby losing prior versions of, the history of a branch. The commit information remains, but the history of how they link together is lost. That is a loss of information, which is not the case in the absence of such history re-writing. Git users differ in whether they consider that information loss important; but it is, objectively, losing history information. So Ethan's impression is correct on this point. It’s not lost, the only thing that’s “gone” is a pointer to the HEAD commit of that branch. Each commit points to it’s parent commit so if you find the HEAD and give it a name you’ll restore the branch. It just so happens inside the reflog you’ll see a list of the old HEADs of branches so you can get the old commit ID from the HEAD there. In addition depending on how you rewrote the branch and if you did anything else there is likely a reference to the old head at ORIG_HEAD. If you don’t have the reflog (this is per copy of the repository, so a different computer or deleting the repo and recreating it will lose it) and for similar reasons you don’t have the ORIG_HEAD, if you have any reference to the previous HEAD (email, commit messages, whatever) that’s enough to restore it assuming that the commits have not been garbage collected yet (which happens in 90 days or 30 days depending on what kind of unreferenced commit it is) you can restore it. The important thing to realize is that a “branch” isn’t anything special in git. All a branch does is act as a sort of symlink to a commit ID. Anything more beyond “what is the HEAD commit in this branch” is stored as part of the commits themselves and doesn’t rely on the branch to be named. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft don...@stufft.io writes: It’s not lost, [… a long, presumably-accurate discourse of the many conditions that must be met before …] you can restore it. This isn't the place to discuss the details of Git's internals, I think. I'm merely pointing out that: The important thing to realize is that a “branch” isn’t anything special in git. Because of that, Ethan's impression – that Git's default behaviour encourages losing history (by re-writing the history of commits to be other than what they were) is true, and “Git never loses history” simply isn't true. Whether that is a *problem* is a matter of debate, but the fact that Git's common workflow commonly discards information that some consider valuable, is a simple fact. If Ethan chooses to make that a factor in his decisions about Git, the facts are on his side. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__)‘us’.” —Douglas Adams | Ben Finney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 7:43 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: It’s not lost, [… a long, presumably-accurate discourse of the many conditions that must be met before …] you can restore it. This isn't the place to discuss the details of Git's internals, I think. I'm merely pointing out that: The important thing to realize is that a “branch” isn’t anything special in git. Because of that, Ethan's impression – that Git's default behaviour encourages losing history (by re-writing the history of commits to be other than what they were) is true, and “Git never loses history” simply isn't true. Whether that is a *problem* is a matter of debate, but the fact that Git's common workflow commonly discards information that some consider valuable, is a simple fact. If Ethan chooses to make that a factor in his decisions about Git, the facts are on his side. Except it’s not true at all. That data is all still there if you want it to exist and it’s not a real differentiator between Mercurial and git because Mercurial has the ability to do the same thing. Never mind the fact that “lose” your history makes it sound accidental instead of on purpose. It’s like saying that ``rm foo.txt`` will “lose” the data in foo.txt. So either it was a misunderstanding in which case I wanted to point out that those operations don’t magically lose information or it’s a purposely FUDish statement in which case I want to point out that the statement is inaccurate. The only thing that is true is that git users are more likely to use the ability to rewrite history than Mercurial users are, but you’ll typically find that people generally don’t do this on public branches, only on private branches. Which again doesn’t make much sense in this context since generally currently the way people are using Mercurial with CPython you’re using patches to transfer the changes from the contributor to the committer so you’re “losing” that history regardless. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 04:31 AM, Paul Moore wrote: On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. I'm curious about These useful extension. Can you elaborate? -- Pierre-Yves David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 08:45 AM, Donald Stufft wrote: I don’t make branches in Mercurial because i’m afraid I’m going to push a permanent branch to hg.python.org http://hg.python.org and screw something up. There is no need to be afraid there, Mercurial is not going to let you push new head/branch unless you explicitly use `hg push --force`. I you are really paranoid about this, you can configure your Mercurial to make all new commit as secret (no pushable) and explicitly make commit ready to push as such. This can be achieved by adding [phases] new-commit=secret See `hg help phases` for details. -- Pierre-Yves David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 11/30/2014 04:31 AM, Paul Moore wrote: On 29 November 2014 at 23:27, Donald Stufftdon...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. Mercurial have robust Windows support for a long time. This support is native (not using cygwin) and handle properly all kind of strange corner case. We have large scale ecosystem (http://unity3d.com/) using Mercurial on windows. We also have full featured GUI client http://tortoisehg.bitbucket.org/. It is actively developed by people who stay in touch with the Mercurial upstream so new feature tend to land in the GUI really fast. -- Pierre-Yves David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014, at 8:11 PM, Pierre-Yves David pierre-yves.da...@ens-lyon.org wrote: On 11/30/2014 08:45 AM, Donald Stufft wrote: I don’t make branches in Mercurial because i’m afraid I’m going to push a permanent branch to hg.python.org http://hg.python.org and screw something up. There is no need to be afraid there, Mercurial is not going to let you push new head/branch unless you explicitly use `hg push --force`. I you are really paranoid about this, you can configure your Mercurial to make all new commit as secret (no pushable) and explicitly make commit ready to push as such. This can be achieved by adding [phases] new-commit=secret See `hg help phases` for details. Yea Benjamin mentioned that the hg.python.org repositories have commit hooks to prevent that from happening too. To be clear the fact I don’t really know Mercurial very well isn’t what I think is a compelling argument for not using Mercurial. It’s mostly a tangent to this PEP which is primarily focused on the “network effects” of using a more popular tool. The technical benefits mostly come from Github generally being a higher quality product than it’s competitors, both FOSS and not. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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/archive%40mail-archive.com
