Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On 29 November 2014 at 03:34, Demian Brecht demianbre...@gmail.com wrote: On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon br...@python.org wrote: I suspect if we make sure we add Bitbucket and GitHub login support to the issue tracker then that would help go a fair distance to helping with the GitHub pull of reach (and if we make it so people can simply paste in their fork's URL into the issue tracker and we simply grab a new patch for review that would go even farther). Chiming in horribly late, so hopefully this hasn't already been mentioned (I've only loosely been following this thread). In addition to the login support (I'm not sold on how much that would help the reach), I think it would be really beneficial to have some documentation on either emulating git-style workflow in hg or detailing a git fork workflow while working on multiple patches concurrently and keeping master in sync with hg default (or perhaps even both). As far as I'm aware, the easiest way to do that by using git-remote-hg to treat the CPython Mercurial repository as a git remote (although I've never tried it myself). Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On 11/28/2014 09:34 AM, Demian Brecht wrote: I primarily use git for development. Having little or no effort to context switch to work on CPython in any capacity (PEPs, code, etc) would be hugely beneficial for me. Having a well defined workflow in the docs (perhaps alongside Lifecycle of a patch?) would have significantly lowered the initial barrier of entry for me. Given the amount of time I put into that initially, I can only imagine how many people it's entirely turned away from contributing. I'd definitely be interested in contributing documentation around this (I've written up something similar here http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/) if others feel that it would be valuable. That would be very valuable, thank you. -- ~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] Move selected documentation repos to PSF BitBucket account?
On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon br...@python.org wrote: I suspect if we make sure we add Bitbucket and GitHub login support to the issue tracker then that would help go a fair distance to helping with the GitHub pull of reach (and if we make it so people can simply paste in their fork's URL into the issue tracker and we simply grab a new patch for review that would go even farther). Chiming in horribly late, so hopefully this hasn't already been mentioned (I've only loosely been following this thread). In addition to the login support (I'm not sold on how much that would help the reach), I think it would be really beneficial to have some documentation on either emulating git-style workflow in hg or detailing a git fork workflow while working on multiple patches concurrently and keeping master in sync with hg default (or perhaps even both). I primarily use git for development. Having little or no effort to context switch to work on CPython in any capacity (PEPs, code, etc) would be hugely beneficial for me. Having a well defined workflow in the docs (perhaps alongside Lifecycle of a patch?) would have significantly lowered the initial barrier of entry for me. Given the amount of time I put into that initially, I can only imagine how many people it's entirely turned away from contributing. I'd definitely be interested in contributing documentation around this (I've written up something similar here http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/) if others feel that it would be valuable. IMHO, you don't want to limit submissions due to the tech stack (one of the arguments I've seen for not moving to Github was quality of submissions). This will also limit high quality work from those who simply don't have time to adopt new tech and workflows when they're not being paid to do so. I have no strong opinion of where and how the official repos are stored so long as I can work on them and contribute to them in the way that's most efficient for me. I imagine that statement would also hold true for most. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Tue, 25 Nov 2014 16:17:06 +1000 Nick Coghlan ncogh...@gmail.com wrote: The subsequent discussion has made me realise that dissatisfaction with the current state of the infrastructure amongst core developers is higher than I previously realised, so I've re-evaluated my own priorities, and will be spending more time on both PEP 474 (forge.python.org) and PEP 462 (the far more complex proposal to consider introducing OpenStack style merge gating for CPython). At present, it looks like significant workflow improvements for the main CPython repos will require custom tooling - there's very little out there that will adequately support a long term maintenance branch, a short term maintenance branch, additional security fix only branches, and a separate main line of development. If something constructive comes out of this surrealistic discussion thread then all the better. Thank you Nick. 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] Move selected documentation repos to PSF BitBucket account?
On Tue Nov 25 2014 at 1:17:49 AM Nick Coghlan ncogh...@gmail.com wrote: On 25 November 2014 at 13:18, Donald Stufft don...@stufft.io wrote: There’s also the social aspects of it as well which is a big concern too IMO. If you want to attract new contributors, not just keep the ones you already have sometimes that means going to where the new contributors are instead of telling them that they need to come to you. Again, the bottleneck at the moment is *reviewing* contributions, not getting more of them. The two aspects are not unrelated, but my key concern at this point is to make the patch review and acceptance process easier, moreso than to increase the rate of incoming patches. My short term proposal to consider BitBucket as an option for support repo hosting purposes was mostly driven by my delays in getting the end-to-end signing PEPs for PyPI updated in a timely fashion - that would have been much easier if the authors had been able to submit pull requests, and I just reviewed and accepted them. And then people thought, ooh, if we are going to open that can of worms we might as well get the better network effect of GitHub along with Guido going git = hg. The subsequent discussion has made me realise that dissatisfaction with the current state of the infrastructure amongst core developers is higher than I previously realised, so I've re-evaluated my own priorities, and will be spending more time on both PEP 474 (forge.python.org) and PEP 462 (the far more complex proposal to consider introducing OpenStack style merge gating for CPython). Yay! At present, it looks like significant workflow improvements for the main CPython repos will require custom tooling - there's very little out there that will adequately support a long term maintenance branch, a short term maintenance branch, additional security fix only branches, and a separate main line of development. Yes, we are unfortunately special. Having our own Kallithea installation would provide additional implementation options on that front, so I'll be keeping that in mind as I work to get the proof-of-concept forge instance online. I think this is a reasonable summary of what came up. Short of Donald and maybe Guido really liking the GitHub idea because of their reach, most of us just want better tooling and we all have various compromises we are willing to make to gain that tooling. I suspect if we make sure we add Bitbucket and GitHub login support to the issue tracker then that would help go a fair distance to helping with the GitHub pull of reach (and if we make it so people can simply paste in their fork's URL into the issue tracker and we simply grab a new patch for review that would go even farther). ___ 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] Move selected documentation repos to PSF BitBucket account?
On 24 Nov 2014 10:41, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 6:57 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html I don’t think this is really all that big of a deal. If we want to move off of Github doing so is easy. It's only easy to leave if you never adopt any GitHub-only services like Travis CI. It's the same lockin play as the one Google uses: make it easy for people to move their data, so they're less likely to notice you're locking them in with proprietary APIs and ecosystems instead. You unlikely to see significant amounts of VC funding pouring into a company unless the investors see a possible chance to extract monopoly rents at some point in the future. Cheers, Nick. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote: I took the git knowledge I acquired by necessity at Red Hat and figured out how to apply it to hg. All the same features are there in hg, they're just switched off by default (mainly because the core Mercurial devs are adamant that any potentially history destroying operation in a version control system must be opt-in). If you could find the time to write up something about that I'm sure it would be helpful. :) The main thing is to enable some of the extensions mentioned in http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table by adding the appropriate entries to ~/.hgrc. A subset of my own extension set: == [extensions] rebase = share = eol = histedit = record = purge = == Share (multiple working directories from a single clone) is nice for a multi-branch project like CPython, while record allows selective commits, rebase allows changeset rebasing (as you might expect), histedit allows interactive history editing (akin to git's interactive rebasing), and pure allows deleting commits entirely. eol is the extension for Windows end of line handling that CPython needs. Several of those are off by default due to Mercurial's policy that anything which risks losing data should be off by default - messy history is considered preferable to potentially losing changes you didn't mean to destroy. git, by contrast, is happy to let users destroy history, and considers it their own fault if they mess it up and lose content irrevocably - thus the plethora of how to use git safely guides, while there's a relative dearth of how to enable history modification in Mercurial guides. The Mercurial team's preferred solution to history modification is changeset evolution, which also version controls any history editing operations so they can be reliably communicated to other users of a shared repo: http://evolution.experimentalworks.net/doc/user-guide.html While that's officially still experimental, it's unlikely to pose significant hazards to anyone coming to Mercurial from git - git's default mode of operation is far more cavalier regarding repository history than evolve will ever be. Another aspect that can be somewhat annoying is the terminology conflict between branches in the git sense and bookmarks vs named branches in the Mercurial sense. In Mercurial, commits made on a branch permanently remember which branch they were made on - you can see in the CPython history, for example, whether a particular commit was made to the 2.7 branch, or the 3.3 branch, etc, just by looking at the commit in isolation. Mercurial bookmarks and git branches, by contrast, are just references to a particular commit that represents the current head of a particular line of development - to find out if a particular commit is on that line of development, you have to trace the commit graph backwards to see if it appears. For a while, Mercurial was also missing support for git-style revision shorthands (you needed an extension to add them), but these days you can do things like hg diff -r tip^ or hg diff -r 'p1()^' to specify relative revset references (while still retaining the full flexibility of Mercurial's programmatic revset syntax if you need it). (Speaking of which, I remembered one key thing which would likely be broken by a switch in the underlying DVCS: the Reitveld/Roundup integration) Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On 24 November 2014 at 10:20, Nick Coghlan ncogh...@gmail.com wrote: Another aspect that can be somewhat annoying is the terminology conflict between branches in the git sense and bookmarks vs named branches in the Mercurial sense. This is probably the thing that hurts me most in git/hg translation. In git, I routinely create branches, play with them, then throw them away (either once they get integrated, or when I decide they are a bad idea). It seems to me to be *much* harder to get that lightweight behaviour in hg - if I create a PR for a hg project that isn't accepted, how do I delete it from my clone? In a way that means it won't reappear when I push/pull from my other PC, where I forgot to *also* delete it? Does the answer to that depend on whether I used a bookmark or a branch (and relatedly, which should I use)? Maybe it's also more complicated than it seems on git, but cleaning up experiments seems much easier to me on git. Not that we're getting offtopic here at all, of course... ;-) 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] Move selected documentation repos to PSF BitBucket account?
Nick Coghlan ncogh...@gmail.com writes: Are you volunteering to write a competing PEP for a migration to git and GitHub? Anyone who does decide to propose either Git or GitHub for hosting Python resources: Please don't conflate the two. Git is a community-supported free-software DVCS system with many viable hosting platforms and providers. GitHub is one proprietary hosting service with features that encourage vendor lock-in, and as Barry Warsaw pointed out it is not answerable to the PSF nor under the PSF's control. There are other hosting solutions without these problems. Everyone here already knows this distinction at some level, but it's far too common to see people assume that an argument in favour of Git will also be a compelling case for GitHub. It isn't, and the case for the latter needs to be made quite separately from the case for the former. No, I'm not offering to write such a PEP either. I'm requesting that we recognise that a promotion of GitHub needs to account for its downsides too, and needs to promote its specific benefits separately from the benefits of Git. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | 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] Move selected documentation repos to PSF BitBucket account?
On 24 November 2014 at 22:01, Donald Stufft don...@stufft.io wrote: On Nov 24, 2014, at 6:44 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: No, I'm not offering to write such a PEP either. I'm requesting that we recognise that a promotion of GitHub needs to account for its downsides too, and needs to promote its specific benefits separately from the benefits of Git. In many cases Github is git’s killer feature which is why you see a lot of people equate the two. It’s not unusual to see a project switch away from X to git entirely so they can use Github. And this is why the you can still get your data out argument doesn't make any sense - if you aren't planning to rely on the proprietary APIs, GitHub is just a fairly mundane git hosting service, not significantly different in capabilities from Gitorious, or RhodeCode, or BitBucket, or GitLab, etc. So you may as well go with one of the open source ones, and be *completely* free from vendor lockin. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 7:09 AM, Nick Coghlan ncogh...@gmail.com wrote: On 24 November 2014 at 22:01, Donald Stufft don...@stufft.io wrote: On Nov 24, 2014, at 6:44 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: No, I'm not offering to write such a PEP either. I'm requesting that we recognise that a promotion of GitHub needs to account for its downsides too, and needs to promote its specific benefits separately from the benefits of Git. In many cases Github is git’s killer feature which is why you see a lot of people equate the two. It’s not unusual to see a project switch away from X to git entirely so they can use Github. And this is why the you can still get your data out argument doesn't make any sense - if you aren't planning to rely on the proprietary APIs, GitHub is just a fairly mundane git hosting service, not significantly different in capabilities from Gitorious, or RhodeCode, or BitBucket, or GitLab, etc. So you may as well go with one of the open source ones, and be *completely* free from vendor lockin. I don’t really agree unless what you’re saying is that the reason it doesn’t make any sense is because you probably won’t want to get your data out because Github’s features are compelling enough that you don’t want to lose them. --- 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 4:12 AM, Nick Coghlan ncogh...@gmail.com wrote: On 24 Nov 2014 10:41, Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: On Nov 23, 2014, at 6:57 PM, Steven D'Aprano st...@pearwood.info mailto:st...@pearwood.info wrote: On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html http://nedbatchelder.com/blog/201405/github_monoculture.html I don’t think this is really all that big of a deal. If we want to move off of Github doing so is easy. It's only easy to leave if you never adopt any GitHub-only services like Travis CI. It's the same lockin play as the one Google uses: make it easy for people to move their data, so they're less likely to notice you're locking them in with proprietary APIs and ecosystems instead. You unlikely to see significant amounts of VC funding pouring into a company unless the investors see a possible chance to extract monopoly rents at some point in the future. Cheers, Nick. Dropping those services is not harder than running those services on our own anyways. It’s unlikely, for instance, that CPython itself would ever be able to use Travis so if we did move to Github and at some point in the future want to move away from Github we’d simply be reverting to the state we’re in now. We wouldn’t be worse off other than we’d have experienced something better than what we have now. I suppose purposely hobbling ourselves so we never get used to something better is a legitimate way to manage things. It’s not different than saying spam filtering is a “vendor lockin” on gmail because if you want to switch away from it in the future you’ll have to set up your own spam filtering. --- 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 2:25 AM, Nick Coghlan ncogh...@gmail.com wrote: On 24 November 2014 at 02:55, Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com wrote: Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Are you volunteering to write a competing PEP for a migration to git and GitHub? I won't be updating PEP 474 to recommend moving to either, as I don't think that would be a good outcome for the Python ecosystem as a whole. It massively undercuts any possible confidence anyone else might have in Mercurial, BitBucket, Rhodecode, Kallithea Allura (all Python based version control, or version control hosting, systems). If we as the Python core development team don't think any of those are good enough to meet the modest version control needs of our support repos, why on earth would anyone else choose them? If those project’s depend on CPython to pick them then they are doomed because we can only pick one. If we pick Bitbucket than the core development team must not think Rhodecode, Kallithea, Allura is good enough so why on earth would anyone choose them? Ditto for any of the other options. In reality, I think most of these services are pretty interchangeable - GitHub's just been the most effective at the venture capital powered mindshare grab business model (note how many of the arguments here stem from the fact folks like *other* things that only interoperate with GitHub, and no other repository hosting providers - that's the core of the A18z funded approach to breaking the D in DVCS and ensuring that GitHub's investors are in a position to clip the ticket when GitHub eventually turns around and takes advantage of its dominant market position to increase profit margins). You’ll see those arguments because the other argument is “softer”, Github just plain works better than Bitbucket does. That's why I consider it legitimate to treat supporting fellow Python community members as the determining factor - a number of the available options meet the good enough bar from a technical perspective, so it's reasonable to take other commercial and community factors into account when making a final decision. Sure it’s completely reasonable to take that into account, I don’t think “Not written in Python” should be a disqualifying statement though. We should pick the best tool for the job. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. If CPython eventually followed suit in migrating to git (as seems inevitable if all the other repos were to switch), then every buildbot will also need to be updated to have git installed (and Mercurial removed). From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. Yes, I agree any real benefit comes from the PR workflow, not from git. This is why I consider written in Python to be a valid determining factor - multiple services meet the good enough
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014 3:12 AM, Nick Coghlan ncogh...@gmail.com wrote: On 24 Nov 2014 10:41, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 6:57 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html I don’t think this is really all that big of a deal. If we want to move off of Github doing so is easy. It's only easy to leave if you never adopt any GitHub-only services like Travis CI. It's the same lockin play as the one Google uses: make it easy for people to move their data, so they're less likely to notice you're locking them in with proprietary APIs and ecosystems instead. - [ ] list of features ranked by stakeholder value - [ ] pingbacks - [ ] in-band build status - [ ] tagging commits with #num - [ ] web standards for integration (HTTP webhooks are the standards here) ... 'Zapier' For this acquisition; is there a feature comparison matrix with alternatives across the top and namespaced features along the side? You unlikely to see significant amounts of VC funding pouring into a company unless the investors see a possible chance to extract monopoly rents at some point in the future. Cheers, Nick. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan ncogh...@gmail.com wrote: On 24 November 2014 at 02:55, Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com wrote: Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Are you volunteering to write a competing PEP for a migration to git and GitHub? Been there, done that, got the PEP number. I'm just trying to speak from the perspective of the person who drove us off of svn and on to hg (as well as drove us off of SourceForge to our own workflow stack). I personally just want a better workflow. As I said at the beginning, I read your PEPs and talked to you about them at PyCon and I want something like that to happen; push button patch acceptance along with CI of patches would go a long way to making accepting patches easier. But as others have pointed out, we just don't have the volunteer time to make them happen ATM, so I'm willing to entertain moving to GitHub or Bitbucket or whatever to improve our situation. I won't be updating PEP 474 to recommend moving to either, as I don't think that would be a good outcome for the Python ecosystem as a whole. It massively undercuts any possible confidence anyone else might have in Mercurial, BitBucket, Rhodecode, Kallithea Allura (all Python based version control, or version control hosting, systems). If we as the Python core development team don't think any of those are good enough to meet the modest version control needs of our support repos, why on earth would anyone else choose them? In reality, I think most of these services are pretty interchangeable - GitHub's just been the most effective at the venture capital powered mindshare grab business model (note how many of the arguments here stem from the fact folks like *other* things that only interoperate with GitHub, and no other repository hosting providers - that's the core of the A18z funded approach to breaking the D in DVCS and ensuring that GitHub's investors are in a position to clip the ticket when GitHub eventually turns around and takes advantage of its dominant market position to increase profit margins). That's why I consider it legitimate to treat supporting fellow Python community members as the determining factor - a number of the available options meet the good enough bar from a technical perspective, so it's reasonable to take other commercial and community factors into account when making a final decision. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. If CPython eventually followed suit in migrating to git (as seems inevitable if all the other repos were to switch), then every buildbot will also need to be updated to have git installed (and Mercurial removed). From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. Yes, I agree any real benefit comes from the PR workflow, not from git.
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote: On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: That outcome would be the antithesis of the PSF's overall mission, This might be a little controversial, but the PSF's mission should not influence a decision of python-dev. If we had to break a tie then yes, I would choose the Python-based solution. But if a superior solution existed and it just happened to not be written in Python I'm not going to sacrifice productivity and the overall health of the project just to promote an inferior tool because they happened to choose Python. The only reason we didn't go with Jira for our issue tracker was because of pressure to not go with a closed-source solution and I was promised volunteers from the FSF to help manage our issue tracker (which never materialized, BTW). This is really what I’m trying to do but I’m apparently not getting my point across very well. I want us to pick the best tool for the job regardless of what language it’s written in. I just so happen to think that the best tool for the job in this case is Github. Yes, I object strongly to the use of GitHub when there are commercially supported services written in Python like BitBucket and RhodeCode available if we want to go the external hosting route, and other options like the RhodeCode derived Kallithea if we want to run a self-hosted forge. RhodeCode are even PSF sponsors - I'm sure they'd be willing to discuss the possibility of hosting core development repos on their service. That's fine if they want to talk about free support, but being a PSF sponsor should not play into it in the slightest, else it's like buying influence. Agreed here too (even then, Github has been a PyCon sponsor for awhile and has even ran their own Python conference in the past). I think it’s kind of shitty to reject and demean someone who has supported the Python community through various means just because their primary language isn’t Python. --- 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 2:25 AM, Nick Coghlan ncogh...@gmail.com wrote: Are you volunteering to write a competing PEP for a migration to git and GitHub? If nobody steps up to do this (and another PEP isn’t accepted before then) I can likely write something up over the upcoming holiday. --- 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] Move selected documentation repos to PSF BitBucket account?
Is there snapshotting? On Mon, Nov 24, 2014 at 10:44 AM, Donald Stufft don...@stufft.io wrote: On Nov 24, 2014, at 2:25 AM, Nick Coghlan ncogh...@gmail.com wrote: Are you volunteering to write a competing PEP for a migration to git and GitHub? If nobody steps up to do this (and another PEP isn’t accepted before then) I can likely write something up over the upcoming holiday. --- 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/wes.turner%40gmail.com -- Wes Turner https://westurner.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On Mon, Nov 24, 2014 at 6:36 PM, Donald Stufft don...@stufft.io wrote: On Nov 24, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote: On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan ncogh...@gmail.com wrote: That outcome would be the antithesis of the PSF's overall mission, This might be a little controversial, but the PSF's mission should not influence a decision of python-dev. If we had to break a tie then yes, I would choose the Python-based solution. But if a superior solution existed and it just happened to not be written in Python I'm not going to sacrifice productivity and the overall health of the project just to promote an inferior tool because they happened to choose Python. The only reason we didn't go with Jira for our issue tracker was because of pressure to not go with a closed-source solution and I was promised volunteers from the FSF to help manage our issue tracker (which never materialized, BTW). This is really what I’m trying to do but I’m apparently not getting my point across very well. I want us to pick the best tool for the job regardless of what language it’s written in. I just so happen to think that the best tool for the job in this case is Github. For peps and devguide repos GitHub would be the best tool, but not for Doc/ and CPython itself. I also agree that GitHub's big green merge button works well for small or middle sized projects. We can just press the merge button for pep and devguide repos, but for Doc/ I think using GitHub or Bitbucket would be painful. Currently, I do the following steps for a typo fix or a minor markup change: * Import the patch if it's provided: hg imp --no-c url * If it's just a typo in the default branch, just verify it and commit: hg commit and hg push * If not: hg update 3.4, hg commit, hg update default, hg merge 3.4, hg push * If it's a markup change, build the documentation locally. It'll take 2-3 minutes. The last two steps would be look tough to follow, it's actually not. I learned Hg when I started to send patches to CPython and learning a couple of commands is not that hard IMO. For GitHub or Bitbucket: * Review the pull request and merge it via the big green merge button. * Ask submitter to send another pull request for the 3.4 branch. If I remember correctly, it's possible to do that from GitHub's UI, but again opening two pull requests to fix a typo or a markup error isn't good. * Or cherrypick it yourself: - Update your local clone - Cherrypick the commit and push * We can use Travis CI to build the documentation on GitHub. I don't think this is a selling point. I tried to fix a broken URL via the edit button in the PyPy repo a couple of weeks ago. At my first try, Bitbucket opened a pull request in my fork. It took me 10-15 minutes to open a pull request correctly. This step would be easier on GitHub. However, I think sending an email to d...@python.org is the easiest solution. --Berker ___ 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] Move selected documentation repos to PSF BitBucket account?
On 25 Nov 2014 02:28, Brett Cannon br...@python.org wrote: On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan ncogh...@gmail.com wrote: On 24 November 2014 at 02:55, Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com wrote: Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Are you volunteering to write a competing PEP for a migration to git and GitHub? Been there, done that, got the PEP number. I'm just trying to speak from the perspective of the person who drove us off of svn and on to hg (as well as drove us off of SourceForge to our own workflow stack). I personally just want a better workflow. As I said at the beginning, I read your PEPs and talked to you about them at PyCon and I want something like that to happen; push button patch acceptance along with CI of patches would go a long way to making accepting patches easier. But as others have pointed out, we just don't have the volunteer time to make them happen ATM, so I'm willing to entertain moving to GitHub or Bitbucket or whatever to improve our situation. It may not have been Guido's intention, but his proposal to undercut the entire Python based version control tooling ecosystem by deeming it entirely unfit for our purposes has caused me to dramatically re-evaluate my own priorities. I consider the status quo to be only mildly annoying, which is why I'd been willing to defer proposing improvements. If folks are seriously contemplating proposing a move to GitHub instead, then that changes the equation significantly. Regards, Nick. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 2:55 PM, Nick Coghlan ncogh...@gmail.com wrote: On 25 Nov 2014 02:28, Brett Cannon br...@python.org mailto:br...@python.org wrote: On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On 24 November 2014 at 02:55, Brett Cannon br...@python.org mailto:br...@python.org wrote: On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Are you volunteering to write a competing PEP for a migration to git and GitHub? Been there, done that, got the PEP number. I'm just trying to speak from the perspective of the person who drove us off of svn and on to hg (as well as drove us off of SourceForge to our own workflow stack). I personally just want a better workflow. As I said at the beginning, I read your PEPs and talked to you about them at PyCon and I want something like that to happen; push button patch acceptance along with CI of patches would go a long way to making accepting patches easier. But as others have pointed out, we just don't have the volunteer time to make them happen ATM, so I'm willing to entertain moving to GitHub or Bitbucket or whatever to improve our situation. It may not have been Guido's intention, but his proposal to undercut the entire Python based version control tooling ecosystem by deeming it entirely unfit for our purposes has caused me to dramatically re-evaluate my own priorities. I think this is a misrepresentation of what Guido said. I’m pretty sure he just said that Github has “won” over the other sites (which if you define winning in terms of who has the mindshare, I think is indisputable) and that he prefers git over hg now. I consider the status quo to be only mildly annoying, which is why I'd been willing to defer proposing improvements. If folks are seriously contemplating proposing a move to GitHub instead, then that changes the equation significantly. Regards, Nick. --- 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] Move selected documentation repos to PSF BitBucket account?
On 25 Nov 2014 06:25, Donald Stufft don...@stufft.io wrote: On Nov 24, 2014, at 2:55 PM, Nick Coghlan ncogh...@gmail.com wrote: It may not have been Guido's intention, but his proposal to undercut the entire Python based version control tooling ecosystem by deeming it entirely unfit for our purposes has caused me to dramatically re-evaluate my own priorities. I think this is a misrepresentation of what Guido said. I’m pretty sure he just said that Github has “won” over the other sites (which if you define winning in terms of who has the mindshare, I think is indisputable) and that he prefers git over hg now. That's how a monopoly play works - you invest heavily in rapid growth, aim to lock in an ecosystem through proprietary APIs, then use that powerful market position to deliver monopoly rents to the initial investors. The pattern repeats because free-as-in-beer is an extraordinarily effective marketing tactic. Cheers, Nick. I consider the status quo to be only mildly annoying, which is why I'd been willing to defer proposing improvements. If folks are seriously contemplating proposing a move to GitHub instead, then that changes the equation significantly. Regards, Nick. --- 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] Move selected documentation repos to PSF BitBucket account?
On 24/11/2014 02:59, Barry Warsaw wrote: On Nov 23, 2014, at 08:55 AM, Guido van Rossum wrote: - Moving from Hg to Git is a fair amount of one-time work For anyone seriously interested in this, even experimentally, I would highly suggest looking at Eric Raymond's reposurgeon code. You can google it or find it covered in the vast discussions of his conversion of the Emacs repository from bazaar to git. I don't know for a fact that it would handle an hg to git conversion, but it's the most likely candidate for something so complex. There's a lot of similarity in the history of the Emacs and Python repositories, having gone through many previous iterations of vcs's - in Python's case, at least cvs, svn, and hg. For what it's worth, Mike Bayer successfully migrated SQLAlchemy from svn to hg and then to git. He now has an amazing system set up whereby commits can be made by contributors through either GitHub or BitBucket, I thought he still had Trac rigged up on sqlalchemy.org, but looks like the issue tracker has migrated to bitbucket... I believe his reasons for moving are similar to those I've read in Guido's posts. I believe he also has notes on what he did and how things are set up... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 3:48 PM, Nick Coghlan ncogh...@gmail.com wrote: On 25 Nov 2014 06:25, Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: On Nov 24, 2014, at 2:55 PM, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: It may not have been Guido's intention, but his proposal to undercut the entire Python based version control tooling ecosystem by deeming it entirely unfit for our purposes has caused me to dramatically re-evaluate my own priorities. I think this is a misrepresentation of what Guido said. I’m pretty sure he just said that Github has “won” over the other sites (which if you define winning in terms of who has the mindshare, I think is indisputable) and that he prefers git over hg now. That's how a monopoly play works - you invest heavily in rapid growth, aim to lock in an ecosystem through proprietary APIs, then use that powerful market position to deliver monopoly rents to the initial investors. The pattern repeats because free-as-in-beer is an extraordinarily effective marketing tactic. I don’t really think this is a fair comparison either. “lock in” here doesn’t make any sense to me unless you define lock-in as any compelling feature what so ever. Wherever a feature Github added was able to be integrated with git itself it did so. PRs for instance could have been done using a proprietary CLI client that uploaded patches which couldn’t be easily exported. Can you please point out in which ways Github has tried to do “vendor lock in” and in addition can you also point out in which ways they don’t apply to Bitbucket which you were previously fine with? As Guido pointed out, the social aspect to a DVCS is an important part of a DCVS and Git (and Github) has that. Others (including yourself) have pointed out that git vs hg itself is largely isomorphic as far as actual technical ability go when you go through and spend the time to figure out what extensions you need and configure them. It’s largely the *other* tooling around it and the relative sizes of the communities. If you want to pick a toolchain that isn’t as popular nor as polished or as well put together for idealogical reasons than that’s fine, but at least be honest about the fact that you’re choosing to prioritize ideology over selecting the best toolchain. --- 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] Move selected documentation repos to PSF BitBucket account?
On 11/24/2014 08:36 AM, Donald Stufft wrote: On Nov 24, 2014, at 11:28 AM, Brett Cannon wrote: This might be a little controversial, but the PSF's mission should not influence a decision of python-dev. Yet what we do can reinforce, or undermine, the PSF. The only reason we didn't go with Jira for our issue tracker was because of pressure to not go with a closed-source solution [...] This is really what I’m trying to do but I’m apparently not getting my point across very well. I want us to pick the best tool for the job regardless of what language it’s written in. As an open source project it behooves us to support open source solutions, even if a better closed-source solution exists. It is sounding to me like GitHub is not, itself, an open solution, even though they may support open source. -- ~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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 8:59 PM, Ethan Furman et...@stoneleaf.us wrote: On 11/24/2014 08:36 AM, Donald Stufft wrote: On Nov 24, 2014, at 11:28 AM, Brett Cannon wrote: This might be a little controversial, but the PSF's mission should not influence a decision of python-dev. Yet what we do can reinforce, or undermine, the PSF. The only reason we didn't go with Jira for our issue tracker was because of pressure to not go with a closed-source solution [...] This is really what I’m trying to do but I’m apparently not getting my point across very well. I want us to pick the best tool for the job regardless of what language it’s written in. As an open source project it behooves us to support open source solutions, even if a better closed-source solution exists. It is sounding to me like GitHub is not, itself, an open solution, even though they may support open source. I’d agree if the tooling was comparable, but at the end of the day the closed source tool is better and more popular. It isn’t Python’s job to fall on the sword in the name of some greater ideology while other languages get to pick the tooling that best enables them to serve the faith that their users have put in them. “Practicality beats Purity” after all. You might lament the fact that the closed source tool is the better option, but the right response to that is to make an OSS alternative that is more, or at least as, compelling as the closed source solution and then market that and win. --- 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] Move selected documentation repos to PSF BitBucket account?
On 11/24/2014 06:27 PM, Donald Stufft wrote: On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote: It is sounding to me like GitHub is not, itself, an open solution, even though they may support open source. I’d agree if the tooling was comparable, but at the end of the day the closed source tool is better and more popular. It isn’t Python’s job to fall on the sword in the name of some greater ideology while other languages get to pick the tooling that best enables them to serve the faith that their users have put in them. “Practicality beats Purity” after all. You might lament the fact that the closed source tool is the better option, but the right response to that is to make an OSS alternative that is more, or at least as, compelling as the closed source solution and then market that and win. Or, make a list of the must-haves from the (for whatever reason) controversial choice, and implement them in our own infrastructure. (Yeah, I guess I'm volunteering to help with that effort. ;) -- ~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] Move selected documentation repos to PSF BitBucket account?
On Nov 24, 2014, at 9:37 PM, Ethan Furman et...@stoneleaf.us wrote: On 11/24/2014 06:27 PM, Donald Stufft wrote: On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote: It is sounding to me like GitHub is not, itself, an open solution, even though they may support open source. I’d agree if the tooling was comparable, but at the end of the day the closed source tool is better and more popular. It isn’t Python’s job to fall on the sword in the name of some greater ideology while other languages get to pick the tooling that best enables them to serve the faith that their users have put in them. “Practicality beats Purity” after all. You might lament the fact that the closed source tool is the better option, but the right response to that is to make an OSS alternative that is more, or at least as, compelling as the closed source solution and then market that and win. Or, make a list of the must-haves from the (for whatever reason) controversial choice, and implement them in our own infrastructure. (Yeah, I guess I'm volunteering to help with that effort. ;) Isn’t that essentially what I said? ;) Unless you were planning to make the implementations on our own infrastructure closed source. Sadly it’s not just a feature matrix that you need to fill out some check boxes, the closed source software in question just flat out *works* better than any of it’s open source counter parts. Tacking on some features onto an existing solution does not compare. There’s also the social aspects of it as well which is a big concern too IMO. If you want to attract new contributors, not just keep the ones you already have sometimes that means going to where the new contributors are instead of telling them that they need to come to you. --- 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] Move selected documentation repos to PSF BitBucket account?
On 25 November 2014 at 13:18, Donald Stufft don...@stufft.io wrote: There’s also the social aspects of it as well which is a big concern too IMO. If you want to attract new contributors, not just keep the ones you already have sometimes that means going to where the new contributors are instead of telling them that they need to come to you. Again, the bottleneck at the moment is *reviewing* contributions, not getting more of them. The two aspects are not unrelated, but my key concern at this point is to make the patch review and acceptance process easier, moreso than to increase the rate of incoming patches. My short term proposal to consider BitBucket as an option for support repo hosting purposes was mostly driven by my delays in getting the end-to-end signing PEPs for PyPI updated in a timely fashion - that would have been much easier if the authors had been able to submit pull requests, and I just reviewed and accepted them. The subsequent discussion has made me realise that dissatisfaction with the current state of the infrastructure amongst core developers is higher than I previously realised, so I've re-evaluated my own priorities, and will be spending more time on both PEP 474 (forge.python.org) and PEP 462 (the far more complex proposal to consider introducing OpenStack style merge gating for CPython). At present, it looks like significant workflow improvements for the main CPython repos will require custom tooling - there's very little out there that will adequately support a long term maintenance branch, a short term maintenance branch, additional security fix only branches, and a separate main line of development. Having our own Kallithea installation would provide additional implementation options on that front, so I'll be keeping that in mind as I work to get the proof-of-concept forge instance online. 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 2:35 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 17:14, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 2:01 AM, Nick Coghlan ncogh...@gmail.com wrote: Travis isn't the only CI system on the internet, and for pure Sphinx documentation cases, ReadTheDocs runs just as well off BitBucket as it does off GitHub. Sure it’s not the only CI system, but as far as I know bitbucket doesn’t have near the integration possible with CI systems. I make a PR on github I get it tested and the merge button turns green to let me know that the tests run. Travis is popular enough that I’ve seen bitbucket projects hosting a mirror on github *just* for travis. In the absence of a proposal to change version control systems (again), the lack of Mercurial hosting on GitHub makes it rather a moot point. Given that we can barely muster up any enthusiasm for rehosting *without* changing version control systems (and the number of CI systems that integrate with hg.python.org repos other than the main CPython one is exactly zero), any proposal that involves doing even *more* work seems doubly doomed. I’d volunteer to do the work to get the PEPs, and possibly other repositories onto Github if we so decided to do so. Don’t let the lack of volunteer stop that because I will find the time to do it if need be. --- 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] Move selected documentation repos to PSF BitBucket account?
On 23 Nov 2014 18:11, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 2:35 AM, Nick Coghlan ncogh...@gmail.com wrote: In the absence of a proposal to change version control systems (again), the lack of Mercurial hosting on GitHub makes it rather a moot point. Given that we can barely muster up any enthusiasm for rehosting *without* changing version control systems (and the number of CI systems that integrate with hg.python.org repos other than the main CPython one is exactly zero), any proposal that involves doing even *more* work seems doubly doomed. I’d volunteer to do the work to get the PEPs, and possibly other repositories onto Github if we so decided to do so. Don’t let the lack of volunteer stop that because I will find the time to do it if need be. It's the other way around: someone would have to volunteer to make the case that switching version control systems will actually help in any way whatsoever with the core reviewer bandwidth problem. We do *not* have a shortage of people wanting to contribute. While ongoing outreach efforts are essential to promote increased diversity in the contributor base and to counter natural attrition, there is currently no major problem that needs solving on that front. CPython is high profile enough that folks are willing to do battle with the current complicated contribution process, so we're already one of the most active open source projects in the world, in *spite* of the problems with the existing workflow. This high level of activity also takes place in spite of the fact that direct corporate investment in paid contributions to the CPython runtime currently don't really reflect the key role that CPython holds in the enterprise Linux, OpenStack, data analysis, and education ecosystems (to name a few where I personally have some level of involvement either personally or through work). Where I believe we *do* have a problem is with failing to make the best possible use of core developer contribution time, as typos and other minor fixes to project (rather than product) documentation are managed through the same offline patch upload process as the reference interpreter itself. (There are other issues as well, but they're out of scope for the current discussion, which is about the support repos, rather than CPython - the same problem exists there, but the solution is unlikely to be as straightforward). Patches getting held up in the review queue for weeks or months is a *huge* barrier to contribution, as it prevents the formation of the positive feedback cycle where having a contribution accepted feels good, so folks are more likely to want to contribute again. In that context, the useful features that a richer repo hosting application can potentially offer are single-click acceptance and merging of documentation changes that aren't directly linked to a specific CPython version, as well as the ability to make trivial fixes to that documentation (like fixing a typo) entirely online. Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. It's also worth keeping in mind that changing the underlying VCS means changing *all* the automation scripts, rather than just updating the configuration settings to reflect a new hosting URL. Orchestrating this kind of infrastructure enhancement for Red Hat *is* my day job, and you almost always want to go for the lowest impact, lowest risk approach that will alleviate the bottleneck you're worried about while changing the smallest possible number of elements in the overall workflow management system. That underlying calculation doesn't really change much even when the units shift from budget dollars to volunteers' time and energy. Regards, Nick. --- 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] Move selected documentation repos to PSF BitBucket account?
Nick Coghlan writes: By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. Let's not get carried away here. The *massive* burden is the moaning from git-haters (is there a 12-step program for them?) Agreed, learning any new VCS is a burden, and git seems harder than most -- but even RMS is swallowing git for Emacs, despite the fact that the g in git doesn't stand for GNU. with your GitHub ID, and the functional isomorphism [git - hg] I agree that there is an isomorphism, but the philosophical restrictions on hg functionality are quite annoying. I do things like git reset and git commit --amend a lot. I tend to commit before getting coffee, but I don't want that in the permanent record -- git rebase --interactive is a good buddy of mine. And so on. hg *deliberately* gets in the way of such workflows (although perhaps it's not as hard to opt in to the necessary features as it used to be). Nevertheless, I tend to agree with you that moving to Github now is a big move. I just think you should avoid the git dox suck argument. I'd also like to mention that in my opinion the network externalities argument is being misused. True, everybody has a github account, and even if they don't, their little sisters do. So what? There are big network externalities involved, but that doesn't necessarily mean that Bitbucket can't catch up, and most projects I know have branches hosted on both Bitbucket and Github (and often SourceForge or Launchpad as well). People who really prefer one or the other for practical reasons can usually use them without too much difficulty, wherever the official repo may be hosted. More likely to have a clear outcome, the main network externality *we* should be concerned with is *within* the Python ecosystem. *If* the big projects whose core members tend not to hang out here so much (NumPy, SciPy, Twisted, Django, ...) are vastly more likely to be found on Bitbucket than Github (or vice versa), I think that's potentially much more important than the little sisters with github accounts. I also agree with you that the facts that Mercurial is a Python application, and I guess so is most of Github, are important. But again, let's not get carried away. Although practicality beats purity applies here. The Github features are very attractive; we need to look at how useful they will be to contributors before deciding that the warm fuzzy Python community is more important. Finally, Guido is right: Github, and to a somewhat lesser extent Bitbucket and Google Code have gotten code hosting right, compared to the *forges. The people who maintain infrastructure for Python are the kind of contributor who would probably spend more time on reviewing and mentoring and release engineering if they weren't maintaining infrastructure as far as I can see. If the infrastructure maintenance can be delegated (it's not clear to me that it can), that would be a big factor. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun, 23 Nov 2014 22:58:02 +0900 Stephen J. Turnbull step...@xemacs.org wrote: Nick Coghlan writes: By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. Let's not get carried away here. The *massive* burden is the moaning from git-haters (is there a 12-step program for them?) Is there a 12-step program for people who can't help commenting on the workflow of core developers and contributors while they don't seem to ever contribute anything concrete? Seriously, stick to the topics where you have some semblant of legitimacy. Whether we choose to use git or hg you have absolutely no authority to comment about. 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014, at 01:25, Nick Coghlan wrote: On 23 November 2014 at 16:03, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Going to all the trouble to move to an external repository and choosing the least popular option out of the two main ones seems like a bad idea in general. Moving repos from hg.python.org to bitbucket.org is just a matter of switching some URLs around, and changing some backend systems to cope with the new location. The end result should be to make life better for existing contributors *and* new contributors using the web UI, and be largely transparent to folks using command line tools. By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. But how many people are there who will have this massive burden imposed on them? I imagine there's few among us who haven't had to learn git for our job or other projects. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sat, Nov 22, 2014 at 10:49 PM, Nick Coghlan ncogh...@gmail.com wrote: More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? That's a really low blow, Nick. I think these are the facts: - Hg/Git are equivalent in functionality (at least to the extent that the difference can't be used to force a decision), and ditto for BitBucket/GitHub, with one crucial exception (see below) - We're currently using Hg for most projects under the PSF umbrella (however, there's https://github.com/python/pythondotorg) - Moving from Hg to Git is a fair amount of one-time work (converting repos) and is inconvenient to core devs who aren't already used to Git (learning a new workflow) - Most newer third-party projects are already on GitHub - GitHub is way more popular than BitBucket and slated for long-term success But here's the kicker for me: **A DVCS repo is a social network, so it matters in a functional way what everyone else is using.** So I give you that if you want a quick move into the modern world, while keeping the older generation of core devs happy (not counting myself :-), BitBucket has the lowest cost of entry. But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. Note: I am not (yet) proposing we switch CPython itself. Switching it would be a lot of work, and it is specifically out of scope for this discussion. -- --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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com wrote: On 23 Nov 2014 18:11, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 2:35 AM, Nick Coghlan ncogh...@gmail.com wrote: In the absence of a proposal to change version control systems (again), the lack of Mercurial hosting on GitHub makes it rather a moot point. Given that we can barely muster up any enthusiasm for rehosting *without* changing version control systems (and the number of CI systems that integrate with hg.python.org repos other than the main CPython one is exactly zero), any proposal that involves doing even *more* work seems doubly doomed. I’d volunteer to do the work to get the PEPs, and possibly other repositories onto Github if we so decided to do so. Don’t let the lack of volunteer stop that because I will find the time to do it if need be. It's the other way around: someone would have to volunteer to make the case that switching version control systems will actually help in any way whatsoever with the core reviewer bandwidth problem. We do *not* have a shortage of people wanting to contribute. While ongoing outreach efforts are essential to promote increased diversity in the contributor base and to counter natural attrition, there is currently no major problem that needs solving on that front. CPython is high profile enough that folks are willing to do battle with the current complicated contribution process, so we're already one of the most active open source projects in the world, in *spite* of the problems with the existing workflow. The *immediate* problem is making it easier to accept contributions from people. The long-term, never-ending problem is making the whole process of submitting a patch and getting it accepted as easy as possible for everyone involved, contributor and committer alike. If the goal is to make it so we can accept PRs for easier patch acceptances then that can be accomplished on either Bitbucket or GitHub. But if we want to make it easier for people to make contributions then GitHub is arguably better than Bitbucket, whether it's through familiarity of GitHub for most people thanks to other FLOSS projects or from the superior tooling around GitHub (both the platform itself and the ecosystem that has sprung up around it). This high level of activity also takes place in spite of the fact that direct corporate investment in paid contributions to the CPython runtime currently don't really reflect the key role that CPython holds in the enterprise Linux, OpenStack, data analysis, and education ecosystems (to name a few where I personally have some level of involvement either personally or through work). Where I believe we *do* have a problem is with failing to make the best possible use of core developer contribution time, as typos and other minor fixes to project (rather than product) documentation are managed through the same offline patch upload process as the reference interpreter itself. (There are other issues as well, but they're out of scope for the current discussion, which is about the support repos, rather than CPython - the same problem exists there, but the solution is unlikely to be as straightforward). Patches getting held up in the review queue for weeks or months is a *huge* barrier to contribution, as it prevents the formation of the positive feedback cycle where having a contribution accepted feels good, so folks are more likely to want to contribute again. In that context, the useful features that a richer repo hosting application can potentially offer are single-click acceptance and merging of documentation changes that aren't directly linked to a specific CPython version, as well as the ability to make trivial fixes to that documentation (like fixing a typo) entirely online. Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 11:55 AM, Brett Cannon br...@python.org wrote: This high level of activity also takes place in spite of the fact that direct corporate investment in paid contributions to the CPython runtime currently don't really reflect the key role that CPython holds in the enterprise Linux, OpenStack, data analysis, and education ecosystems (to name a few where I personally have some level of involvement either personally or through work). Where I believe we *do* have a problem is with failing to make the best possible use of core developer contribution time, as typos and other minor fixes to project (rather than product) documentation are managed through the same offline patch upload process as the reference interpreter itself. (There are other issues as well, but they're out of scope for the current discussion, which is about the support repos, rather than CPython - the same problem exists there, but the solution is unlikely to be as straightforward). Patches getting held up in the review queue for weeks or months is a *huge* barrier to contribution, as it prevents the formation of the positive feedback cycle where having a contribution accepted feels good, so folks are more likely to want to contribute again. In that context, the useful features that a richer repo hosting application can potentially offer are single-click acceptance and merging of documentation changes that aren't directly linked to a specific CPython version, as well as the ability to make trivial fixes to that documentation (like fixing a typo) entirely online. Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. Commit hooks don’t work on Github or bitbucket anyways. So either way they’d need rewritten to support whichever platform’s web hooks instead. From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. Right, I would argue that Github is at least a little bit better because of the commit status API. It’s *really* nice to see right on a PR if it breaks anything or not before you merge it without ever having to run a thing manually. That isn’t something that only Travis can do so if we want some other system to do it that’s totally possible. It's also worth keeping in mind that changing the underlying VCS means changing *all* the automation scripts, rather than just updating the configuration settings to reflect a new hosting URL. What are the automation scripts there are that would require updating? I would like to a list and to have the difficulty of moving them mentioned to know what the impact would be. Off the top of my head for the docs I know of https://github.com/python/docsbuild-scripts/blob/master/build_docs.py https://github.com/python/docsbuild-scripts/blob/master/build_docs.py which will need to be updated to git clone
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On 11/22/2014 11:13 PM, Donald Stufft wrote: On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote: I took the git knowledge I acquired by necessity at Red Hat and figured out how to apply it to hg. All the same features are there in hg, they're just switched off by default (mainly because the core Mercurial devs are adamant that any potentially history destroying operation in a version control system must be opt-in). If you could find the time to write up something about that I'm sure it would be helpful. :) We already have lots of potential contributors (if we didn't, review bandwidth wouldn't be the bottleneck the way it is today), and the functional differences between GitHub and BitBucket from a barrier to entry perspective are so low as to be trivial. That’s not really true. It’s more than just “can I log in”, potential contributors are more likely to already know how to use Github too and are more likely to not want to deal with another site. I know personally if I see a project is on bitbucket my chances of contributing to that project drop drastically, even if they are using git on bitbucket, just because I know that I’m going to get frustrated to some degree. I feel the same way, only in reverse. I've learned hg, and to a lesser extent bitbucket, but have not learned git nor github, and would rather not (available bandwidth and all that). Moving from self-hosted Mercurial repos to externally hosted Mercurial repos is a low risk change. It reduces maintenance overhead and lowers barriers to external contribution, both without alienating existing contributors by forcing them to change their workflows. Proposing to *also* switch from Mercurial to git significantly increases the cost of the change, while providing minimal incremental benefit. Whatever our personal feelings of hg vs git, and bitbucket vs github, that makes sense. -- ~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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 08:55 AM, Brett Cannon wrote: Sure, but I would never compare our infrastructure needs to Red Hat. =) You also have to be conservative in order to minimize downtown and impact for cost reasons. As an open source project we don't have those kinds of worry; we just have to worry about keeping everyone happy. Minimizing downtime and impact is important for us, too. The Python job board has now been down for nine months -- that's hardly good PR. -- ~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] Move selected documentation repos to PSF BitBucket account?
I can agree with most of these points. Some more things to consider: - Git is 20x faster than Hg (that's 99% of the reason I switched and hate using Darcs) - People attached to Hg can use Hg-Git; I've used it several times with nice results. It can also be used to easily convert Hg repos to Git (I was using it to maintain a Pygments mirror, but got bored) - GitHub is much nicer than BitBucket. I usually look for a git mirror of a BitBucket repo since I hate browsing on BB - Even Plan9Port moved from Hg to GitHub a few days ago - Some Google devs even host their projects on GitHub (not Google Code) Thank goodness no one has mentioned CodePlex. BTW, I frown on projects that choose something largely inferior over a better choice just because one is written in X language. Now, if python.org was written in Ruby, that would just be sad, but certain things just don't matter. Like DVCS's. Guido van Rossum gu...@python.org wrote: On Sat, Nov 22, 2014 at 10:49 PM, Nick Coghlan ncogh...@gmail.com wrote: More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? That's a really low blow, Nick. I think these are the facts: - Hg/Git are equivalent in functionality (at least to the extent that the difference can't be used to force a decision), and ditto for BitBucket/GitHub, with one crucial exception (see below) - We're currently using Hg for most projects under the PSF umbrella (however, there's https://github.com/python/pythondotorg) - Moving from Hg to Git is a fair amount of one-time work (converting repos) and is inconvenient to core devs who aren't already used to Git (learning a new workflow) - Most newer third-party projects are already on GitHub - GitHub is way more popular than BitBucket and slated for long-term success But here's the kicker for me: **A DVCS repo is a social network, so it matters in a functional way what everyone else is using.** So I give you that if you want a quick move into the modern world, while keeping the older generation of core devs happy (not counting myself :-), BitBucket has the lowest cost of entry. But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. Note: I am not (yet) proposing we switch CPython itself. Switching it would be a lot of work, and it is specifically out of scope for this discussion. -- --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/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/___ 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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 08:55 AM, Brett Cannon wrote: Fourth, do any core developers feel strongly about not using GitHub? Dous GitHub support hg? If not, I am strongly opposed. -- ~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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 1:06:18 PM Ethan Furman et...@stoneleaf.us wrote: On 11/23/2014 08:55 AM, Brett Cannon wrote: Sure, but I would never compare our infrastructure needs to Red Hat. =) You also have to be conservative in order to minimize downtown and impact for cost reasons. As an open source project we don't have those kinds of worry; we just have to worry about keeping everyone happy. Minimizing downtime and impact is important for us, too. The Python job board has now been down for nine months -- that's hardly good PR. That has nothing to do with downtime and everything to do with volunteer time. My point about downtime is that if I can't commit to the cpython repo for a day it isn't going to cause me to freak out or cost anyone thousands of dollars or more in revenue. -Brett -- ~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/ 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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman et...@stoneleaf.us wrote: On 11/23/2014 08:55 AM, Brett Cannon wrote: Fourth, do any core developers feel strongly about not using GitHub? Dous GitHub support hg? If not, I am strongly opposed. Depends on what you mean by support. If you mean natively, then no. If you mean I want more of a hg CLI then you can get that with http://hg-git.github.io/ . And can I just say this is all bringing back wonderful flashbacks of the SourceForge to our own infrastructure move as well as the svn to hg move. =/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 11:56:49 AM Guido van Rossum gu...@python.org wrote: On Sat, Nov 22, 2014 at 10:49 PM, Nick Coghlan ncogh...@gmail.com wrote: More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? That's a really low blow, Nick. I think these are the facts: - Hg/Git are equivalent in functionality (at least to the extent that the difference can't be used to force a decision), and ditto for BitBucket/GitHub, with one crucial exception (see below) - We're currently using Hg for most projects under the PSF umbrella (however, there's https://github.com/python/pythondotorg) - Moving from Hg to Git is a fair amount of one-time work (converting repos) and is inconvenient to core devs who aren't already used to Git (learning a new workflow) - Most newer third-party projects are already on GitHub - GitHub is way more popular than BitBucket and slated for long-term success But here's the kicker for me: **A DVCS repo is a social network, so it matters in a functional way what everyone else is using.** So I give you that if you want a quick move into the modern world, while keeping the older generation of core devs happy (not counting myself :-), BitBucket has the lowest cost of entry. But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. Note: I am not (yet) proposing we switch CPython itself. Switching it would be a lot of work, and it is specifically out of scope for this discussion. If we want to test the complexity of moving something to GitHub then probably the best repo to use is the peps one: - Very few people directly use that repo (you and me alone could probably manage it if we enforced all changes through a PR as I could then do approvals from work instead of having to wait until I was at home with an hg checkout available) - It's used on the website so it would require updating infrastructure - It isn't a lot of overhead to tell people who email the peps mailing list to please send a pull request through GitHub since it isn't tracked in the issue tracker anyway - There is a benefit of setting up some CI integration to know when a PR is actually incorrectly formatted And if people want to test the impact of Bitbucket we could do it for something like the HOWTOs as that too involves infrastructure but is not used by a lot of people. In fact we can make it known we are piloting this approach on Bitbucket and see what kind of contributions it triggers (ditto for the peps since I'm sure some people will want to send in typo PRs and such). IOW I don't see why we can't pilot this between now and April for the language summit and see what difference it all makes so we can have an informed discussion in Montreal with more than 4 full months of experience under our belts. Then we can discuss Bitbucket vs. GitHub, docs vs. everything moving vs. nothing, etc. That was this stops all being conjecture and more about seeing if there is an actual impact. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 1:31:36 PM Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 11:56:49 AM Guido van Rossum gu...@python.org wrote: On Sat, Nov 22, 2014 at 10:49 PM, Nick Coghlan ncogh...@gmail.com wrote: More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? That's a really low blow, Nick. I think these are the facts: - Hg/Git are equivalent in functionality (at least to the extent that the difference can't be used to force a decision), and ditto for BitBucket/GitHub, with one crucial exception (see below) - We're currently using Hg for most projects under the PSF umbrella (however, there's https://github.com/python/pythondotorg) - Moving from Hg to Git is a fair amount of one-time work (converting repos) and is inconvenient to core devs who aren't already used to Git (learning a new workflow) - Most newer third-party projects are already on GitHub - GitHub is way more popular than BitBucket and slated for long-term success But here's the kicker for me: **A DVCS repo is a social network, so it matters in a functional way what everyone else is using.** So I give you that if you want a quick move into the modern world, while keeping the older generation of core devs happy (not counting myself :-), BitBucket has the lowest cost of entry. But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. Note: I am not (yet) proposing we switch CPython itself. Switching it would be a lot of work, and it is specifically out of scope for this discussion. If we want to test the complexity of moving something to GitHub then probably the best repo to use is the peps one: - Very few people directly use that repo (you and me alone could probably manage it if we enforced all changes through a PR as I could then do approvals from work instead of having to wait until I was at home with an hg checkout available) - It's used on the website so it would require updating infrastructure - It isn't a lot of overhead to tell people who email the peps mailing list to please send a pull request through GitHub since it isn't tracked in the issue tracker anyway - There is a benefit of setting up some CI integration to know when a PR is actually incorrectly formatted And if people want to test the impact of Bitbucket we could do it for something like the HOWTOs as that too involves infrastructure but is not used by a lot of people. In fact we can make it known we are piloting this approach on Bitbucket and see what kind of contributions it triggers (ditto for the peps since I'm sure some people will want to send in typo PRs and such). Actually the tutorial might be best to measure ease of contribution for people on Bitbucket since we can also ask people who use the tutorial to test out pointing people to the Bitbucket repo if people want to send a PR. ___ 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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 10:14 AM, Brett Cannon wrote: On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman et...@stoneleaf.us wrote: Dous GitHub support hg? If not, I am strongly opposed. Depends on what you mean by support. If you mean natively, then no. If you mean I want more of a hg CLI then you can get that with http://hg-git.github.io/ . Well, if somebody documents it, I suppose I can follow along. ;) And can I just say this is all bringing back wonderful flashbacks of the SourceForge to our own infrastructure move as well as the svn to hg move. =/ My apologies. Change can be hard. My concern is that we will end up with multiple different workflows depending on which part of Python we're working on, which will lead to more time spent learning more about how to do it instead of doing it, and more time spent recovering from errors because of the differences. -- ~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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 10:31 AM, Brett Cannon wrote: If we want to test the complexity of moving something to GitHub then probably the best repo to use is the peps one: And if people want to test the impact of Bitbucket we could do it for something like the HOWTOs as that too involves infrastructure but is not used by a lot of people. +1 -- ~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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 1:41 PM, Ethan Furman et...@stoneleaf.us wrote: On 11/23/2014 10:14 AM, Brett Cannon wrote: On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman et...@stoneleaf.us wrote: Dous GitHub support hg? If not, I am strongly opposed. Depends on what you mean by support. If you mean natively, then no. If you mean I want more of a hg CLI then you can get that with http://hg-git.github.io/ . Well, if somebody documents it, I suppose I can follow along. ;). I haven't used it in a while, but it was something like this (after it's installed): - Put the git repo url in .hgrc: [paths] default=git+https://github.com/my_user/my_repo.git [auth] github.prefix = git+https://github.com/my_user/my_repo.git github.username = my_user github.password = my_password Unless you put the login info there, it won't work (for some reason). Then, whenever you're going to push, first do: hg bookmark -r default master I'd love to test this right now, but I'm on Chrome OS... And can I just say this is all bringing back wonderful flashbacks of the SourceForge to our own infrastructure move as well as the svn to hg move. =/ My apologies. Change can be hard. My concern is that we will end up with multiple different workflows depending on which part of Python we're working on, which will lead to more time spent learning more about how to do it instead of doing it, and more time spent recovering from errors because of the differences. -- ~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/rymg19%40gmail.com -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated. Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 05:55 PM, Brett Cannon wrote: I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Well, since most people already know git this part is probably not a big deal, although we'd have to consider alienating core developers who are not git-savvy. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. There are two categories of hooks we use: hooks that run before a push is accepted, and hooks that run afterwards. The latter are not a concern, since anything that GH/BB doesn't support can be run as a web service on python.org infrastructure, which then gets POST requests from the hosting platforms. These are * tracker update * IRC notification * sending email to python-checkins * triggering buildbot The more problematic category are pre-push hooks. We use them for checking and rejecting commits with * disallowed branches * non-conformant whitespace * wrong EOL style * multiple heads per named branch As far as I know, neither GH nor BB support such hooks, since they are highly project-specific. However, they are only used in cpython and related repositories, so that doesn't concern migration of doc-only repos. Sure, you can let the CI run the checks, but that doesn't prohibit merging and is circumvented by direct pushes to the repository that don't go through the PR system. (And please don't make me as a coredev open a PR for every change.) From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. In my opinion, scattering repos over github, bitbucket and hg.python.org is even less friendly to contributors than a centralized place. (We are already approaching this, with pydotorg and infrastructure repos on github.) So I'm going to add some thoughts here about migrating the main CPython to git+hub. We have to consider how well our branch workflow works with the PR workflow. There's no gain in the ability to easily merge a PR to one branch via github when the subsequent merge of 3.x to default/master requires a local pull/push cycle, as well as the 2.x backport. As far as I know, you'd have to open a pull/merge request yourself and instantly merge it, except if there are conflicts between branches, in which case you are again forced to go local. I don't need to mention that this doesn't work well when someone makes a concurrent commit to the source branch in the meantime. And I don't think you'd want to force people to submit 3 pull requests for the individual branches. The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. It's also worth keeping in mind that changing the underlying VCS means changing *all* the automation scripts, rather than just updating the configuration settings to reflect a new hosting URL. What are the automation scripts there are that would require updating? I would like to a list and to have the difficulty of moving them mentioned to know what the impact would be. Compiling that list is likely the most difficult step of
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 07:03 PM, Ryan wrote: I can agree with most of these points. Some more things to consider: - Git is 20x faster than Hg (that's 99% of the reason I switched and hate using Darcs) You won't get much traction with this argument around here. As long as there aren't specific complaints about slowness (which probably could be fixed by a discussion on mercurial-devel), Hg is fast enough, just like Python is fast enough compared to C. (Otherwise, why bother.) - GitHub is much nicer than BitBucket. I usually look for a git mirror of a BitBucket repo since I hate browsing on BB I agree, Github's UI is nicer than BB. It is also true that most features that are introduced on BB are inspired by GH. - Even Plan9Port moved from Hg to GitHub a few days ago Projects move all the time. Why is this one special? - Some Google devs even host their projects on GitHub (not Google Code) Thank goodness no one has mentioned CodePlex. BTW, I frown on projects that choose something largely inferior over a better choice just because one is written in X language. Now, if python.org http://python.org was written in Ruby, that would just be sad, but certain things just don't matter. Like DVCS's. You can read up PEP 374 for the reasons for Hg. The main reasons against git were lacking Windows support (which probably is good enough now) and developer preference. 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 3:03 PM, Georg Brandl g.bra...@gmx.net wrote: The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. This in particular is not really true on Github at least. By default PRs are made against whichever branch you have configured as the default branch in the Github UI. This does default to master but it doesn’t have to be, for instance pip has this configured for the develop branch. Although I think this specific point is moot because if things were on Git it’d probably make the most sense to have the default integration branch be ``master`` just like for the Hg repos they use default. Even if someone makes a PR against the wrong branch, it “degrades” into essentially the same UX as you have now, you can turn a PR into a patch by adding a .patch or .diff to the end of the PR URL and then you have a patch file. In additional github makes it easy to check out PRs directly with only a minor bit of one time configuration in your local clone. I can checkout any PR by doing ``git checkout pr/1`` (replacing 1 with whatever the number is). Honestly the worst part about someone sending a PR to the wrong branch is it degrades into the same terrible UX that *every* patch has to go through on a hg.python.org repository right now. --- 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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 3:04:05 PM Georg Brandl g.bra...@gmx.net wrote: On 11/23/2014 05:55 PM, Brett Cannon wrote: I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Well, since most people already know git this part is probably not a big deal, although we'd have to consider alienating core developers who are not git-savvy. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. There are two categories of hooks we use: hooks that run before a push is accepted, and hooks that run afterwards. The latter are not a concern, since anything that GH/BB doesn't support can be run as a web service on python.org infrastructure, which then gets POST requests from the hosting platforms. These are * tracker update * IRC notification * sending email to python-checkins * triggering buildbot The more problematic category are pre-push hooks. We use them for checking and rejecting commits with * disallowed branches * non-conformant whitespace * wrong EOL style * multiple heads per named branch As far as I know, neither GH nor BB support such hooks, since they are highly project-specific. However, they are only used in cpython and related repositories, so that doesn't concern migration of doc-only repos. Sure, you can let the CI run the checks, but that doesn't prohibit merging and is circumvented by direct pushes to the repository that don't go through the PR system. (And please don't make me as a coredev open a PR for every change.) I'm not even going to touch the idea of requiring code review for all patches in the middle of this discussion. =) From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. In my opinion, scattering repos over github, bitbucket and hg.python.org is even less friendly to contributors than a centralized place. (We are already approaching this, with pydotorg and infrastructure repos on github.) So I'm going to add some thoughts here about migrating the main CPython to git+hub. I don't think we would ever split ourselves across three separate hosting services. At most I see two -- one for docs, one for CPython -- but I would honestly expect it to be only one long-term. We have to consider how well our branch workflow works with the PR workflow. There's no gain in the ability to easily merge a PR to one branch via github when the subsequent merge of 3.x to default/master requires a local pull/push cycle, as well as the 2.x backport. As far as I know, you'd have to open a pull/merge request yourself and instantly merge it, except if there are conflicts between branches, in which case you are again forced to go local. I don't need to mention that this doesn't work well when someone makes a concurrent commit to the source branch in the meantime. And I don't think you'd want to force people to submit 3 pull requests for the individual branches. The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 09:38 PM, Donald Stufft wrote: On Nov 23, 2014, at 3:03 PM, Georg Brandl g.bra...@gmx.net wrote: The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. This in particular is not really true on Github at least. By default PRs are made against whichever branch you have configured as the default branch in the Github UI. This does default to master but it doesn’t have to be, for instance pip has this configured for the develop branch. Although I think this specific point is moot because if things were on Git it’d probably make the most sense to have the default integration branch be ``master`` just like for the Hg repos they use default. Sure, although as is the majority of commits to CPython are bugfixes, which normally go to 2.7, 3.4 and 3.5 (master). Even if someone makes a PR against the wrong branch, it “degrades” into essentially the same UX as you have now, you can turn a PR into a patch by adding a .patch or .diff to the end of the PR URL and then you have a patch file. In additional github makes it easy to check out PRs directly with only a minor bit of one time configuration in your local clone. I can checkout any PR by doing ``git checkout pr/1`` (replacing 1 with whatever the number is). Honestly the worst part about someone sending a PR to the wrong branch is it degrades into the same terrible UX that *every* patch has to go through on a hg.python.org repository right now. I'm not saying it's worse, but most of the time it's no better for the committer, especially since the branches have to be juggled in most cases. Although, when it's the same amount of work for the committer, but nicer for the contributor, that's a net win, I can see that. What is absolutely essential though is a way to automatically open an issue on bugs.python.org for each PR, otherwise we have to look for issues in two different places. (Sure, GH treats PRs like GH issues, but we wouldn't use the GH issue tracker.) 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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 09:42 PM, Brett Cannon wrote: The more problematic category are pre-push hooks. We use them for checking and rejecting commits with * disallowed branches * non-conformant whitespace * wrong EOL style * multiple heads per named branch As far as I know, neither GH nor BB support such hooks, since they are highly project-specific. However, they are only used in cpython and related repositories, so that doesn't concern migration of doc-only repos. Sure, you can let the CI run the checks, but that doesn't prohibit merging and is circumvented by direct pushes to the repository that don't go through the PR system. (And please don't make me as a coredev open a PR for every change.) I'm not even going to touch the idea of requiring code review for all patches in the middle of this discussion. =) As far as I can see, our Rietveld is very well used already. *Requiring* code review for *all* patches is detrimental in a volunteer project IMO. (I'm saying this especially because many of my changes are small to trivial doc fixes.) The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. How do other projects tend to manage their bugfix vs. in-dev branches? Is it a lot of cherrypicking? Probably our long development cycles doesn't help with this as it makes cross-branch merging difficult thanks to divergence, else this could be automated somehow or simply not be an issue. Otherwise we would have to do a merge from branch to branch locally as we do now and make sure people committed in the branch we wanted them to. For smaller projects, it's not as much of an issue. In Sphinx, there are two branches (stable and default), and when there are pull requests to the default branch that should go to stable, I cherry-pick them manually. And as you said, merging or transplanting between branches is much more likely to succeed automatically. The but it is much easier to contribute simple changes argument is a bit simplified: for any nontrivial patch, the time spent on working out the code should outweight time spent with hg diff or click on pull request. And while Travis CI is nice, running relevant tests locally is *much* quicker than waiting for a full test suite run on a virtualized testing machine. Sure, but it's definitely easier to just wait for the Travis green on the PR than have to apply a patch and run the tests myself manually. You'll likely have to run them manually anyway while merging to the other branches. As for typo fixes, the world does not end when some typos aren't fixed. Anyway, for the docs we have an explicit offer to send anything, patch or just suggestion, to d...@python.org mailto:d...@python.org, and people do make use of it. No github account even required. Which is great, but I'm willing to bet clicking Edit in GitHub is easier still than creating the patch and emailing it. I have contributed doc fixes to a bunch of projects because of that Edit button (which is why I think Nick is so anxious to get it). If I had to do any checkout then I wouldn't have done them. And even having to email a diff might be too much for some changes. I did say patch or just suggestion. Most emails to d...@python.org come without a patch, just a plain description of what's wrong, and that is just fine. I would also judge that 50% of the emails come from people who wouldn't have a github account in any case (so that the big shiny Edit button isn't an easy option). And I'm still in support no matter what of breaking out the HOWTOs and the tutorial into their own repos for easier updating (having to update the Python porting HOWTO in three branches is a pain when it should be consistent across Python releases). I see no problem with that, provided there's a cronjob that syncs the version in Doc/ to the external version reasonably often. Would that really be necessary? At least for the HOWTOs how often are they edited simultaneously as some code in CPython? The Clinic HOWTO is probably the only one that might get updated simultaneously. I'd also be curious to know how often the tutorial is updated simultaneously as well. I'd like the HOWTOs to stay part of Doc/, so changes in the external repo have to be merged in there somehow, and not only at release time. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 4:08 PM, Georg Brandl g.bra...@gmx.net wrote: On 11/23/2014 09:38 PM, Donald Stufft wrote: On Nov 23, 2014, at 3:03 PM, Georg Brandl g.bra...@gmx.net wrote: The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. This in particular is not really true on Github at least. By default PRs are made against whichever branch you have configured as the default branch in the Github UI. This does default to master but it doesn’t have to be, for instance pip has this configured for the develop branch. Although I think this specific point is moot because if things were on Git it’d probably make the most sense to have the default integration branch be ``master`` just like for the Hg repos they use default. Sure, although as is the majority of commits to CPython are bugfixes, which normally go to 2.7, 3.4 and 3.5 (master). Even if someone makes a PR against the wrong branch, it “degrades” into essentially the same UX as you have now, you can turn a PR into a patch by adding a .patch or .diff to the end of the PR URL and then you have a patch file. In additional github makes it easy to check out PRs directly with only a minor bit of one time configuration in your local clone. I can checkout any PR by doing ``git checkout pr/1`` (replacing 1 with whatever the number is). Honestly the worst part about someone sending a PR to the wrong branch is it degrades into the same terrible UX that *every* patch has to go through on a hg.python.org repository right now. I'm not saying it's worse, but most of the time it's no better for the committer, especially since the branches have to be juggled in most cases. Right, well if you’re just merging one branch into another you can create a PR from one branch to another directly in the Github Web UI, which will run tests and then you can press the merge button on that PR too. It’s something like 3-4 clicks or so. If you want to selectively send a change from one branch to another that will require manually making the change locally yea. Although, when it's the same amount of work for the committer, but nicer for the contributor, that's a net win, I can see that. What is absolutely essential though is a way to automatically open an issue on bugs.python.org for each PR, otherwise we have to look for issues in two different places. (Sure, GH treats PRs like GH issues, but we wouldn't use the GH issue tracker.) There’s a web hook that fires when a pull request is created, it could even be smart enough to look for Issue numbers in the PR and commits so that it associates it with an existing issue instead of creating a new issue. You can see all of the events we can subscribe to here: https://developer.github.com/webhooks/#events In a related note, while it’s not possible to *reject* a push if things don’t match up it is entirely possible to detect it after the fact and send an email out to folks or what have you. Similar to how tests themselves are done now. --- 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] Move selected documentation repos to PSF BitBucket account?
Georg Brandl g.bra...@gmx.net wrote: On 11/23/2014 07:03 PM, Ryan wrote: I can agree with most of these points. Some more things to consider: - Git is 20x faster than Hg (that's 99% of the reason I switched and hate using Darcs) You won't get much traction with this argument around here. As long as there aren't specific complaints about slowness (which probably could be fixed by a discussion on mercurial-devel), Hg is fast enough, just like Python is fast enough compared to C. (Otherwise, why bother.) I know, but, when checking out large repos, it stings a little. - GitHub is much nicer than BitBucket. I usually look for a git mirror of a BitBucket repo since I hate browsing on BB I agree, Github's UI is nicer than BB. It is also true that most features that are introduced on BB are inspired by GH. - Even Plan9Port moved from Hg to GitHub a few days ago Projects move all the time. Why is this one special? Because, for ages, everything related to Rob Pike used Google Code and Mercurial, largely because he works at Google. - Some Google devs even host their projects on GitHub (not Google Code) Thank goodness no one has mentioned CodePlex. BTW, I frown on projects that choose something largely inferior over a better choice just because one is written in X language. Now, if python.org http://python.org was written in Ruby, that would just be sad, but certain things just don't matter. Like DVCS's. You can read up PEP 374 for the reasons for Hg. The main reasons against git were lacking Windows support (which probably is good enough now) and developer preference. 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/rymg19%40gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On 11/23/2014 3:18 AM, Nick Coghlan wrote: Patches getting held up in the review queue for weeks or months is a *huge* barrier to contribution, as it prevents the formation of the positive feedback cycle where having a contribution accepted feels good, so folks are more likely to want to contribute again. Exactly. None of the patches I care about have gone anywhere for years. Two of them were done by others, apparently using the right processes, and still went nowhere, so it doesn't encourage me to attempt to even learn the process to make a more appropriate contribution of mine (which, sadly, I fixed too many different bugs in one file or two files, and have not split them into individual patches). Another has recently been making some progress... I guess that means I don't care enough about them, to fight to force them through the system, it is easier just to apply the patches to my installation... but that is a sad state of affairs. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun Nov 23 2014 at 4:18:37 PM Georg Brandl g.bra...@gmx.net wrote: On 11/23/2014 09:42 PM, Brett Cannon wrote: [SNIP] And I'm still in support no matter what of breaking out the HOWTOs and the tutorial into their own repos for easier updating (having to update the Python porting HOWTO in three branches is a pain when it should be consistent across Python releases). I see no problem with that, provided there's a cronjob that syncs the version in Doc/ to the external version reasonably often. Would that really be necessary? At least for the HOWTOs how often are they edited simultaneously as some code in CPython? The Clinic HOWTO is probably the only one that might get updated simultaneously. I'd also be curious to know how often the tutorial is updated simultaneously as well. I'd like the HOWTOs to stay part of Doc/, so changes in the external repo have to be merged in there somehow, and not only at release time. Right, I'm trying to understand *why* you want the HOWTOs to stay in Doc/. I dread having to update the porting HOWTO because it requires updating 2.7, 3.4, and default. And if the process is automated to pull from an external repo then what is the benefit of syncing the files and duplicating them across 4 repos? ___ 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] Move selected documentation repos to PSF BitBucket account?
On 11/24/2014 12:21 AM, Brett Cannon wrote: On Sun Nov 23 2014 at 4:18:37 PM Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: On 11/23/2014 09:42 PM, Brett Cannon wrote: [SNIP] And I'm still in support no matter what of breaking out the HOWTOs and the tutorial into their own repos for easier updating (having to update the Python porting HOWTO in three branches is a pain when it should be consistent across Python releases). I see no problem with that, provided there's a cronjob that syncs the version in Doc/ to the external version reasonably often. Would that really be necessary? At least for the HOWTOs how often are they edited simultaneously as some code in CPython? The Clinic HOWTO is probably the only one that might get updated simultaneously. I'd also be curious to know how often the tutorial is updated simultaneously as well. I'd like the HOWTOs to stay part of Doc/, so changes in the external repo have to be merged in there somehow, and not only at release time. Right, I'm trying to understand *why* you want the HOWTOs to stay in Doc/. I dread having to update the porting HOWTO because it requires updating 2.7, 3.4, and default. And if the process is automated to pull from an external repo then what is the benefit of syncing the files and duplicating them across 4 repos? That they are still part of the docs on docs.python.org and what people download from there. I don't like resources like that scattered about. It makes sense for the devguide, since that is really a different topic. 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. I'm sure that we'll get *more* contributions, but will they be *better* contributions? I know that there are people who think that mailing lists are old and passe, and that we should shift discussion to a social media site like Reddit. If we did, we'd probably get twenty times as many comments, and the average quality would probably plummet. More is not necessarily a good thing. -- 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html I promise you that once the pain of the switch is over you will feel much better about it. I am also convinced that we'll get more contributions this way. I'm sure that we'll get *more* contributions, but will they be *better* contributions? I know that there are people who think that mailing lists are old and passe, and that we should shift discussion to a social media site like Reddit. If we did, we'd probably get twenty times as many comments, and the average quality would probably plummet. More is not necessarily a good thing. If we need to ensure that we're getting better contributions than we are now, then we should be interviewing committers, rejecting newcomers (or the opposite, multiplying core-mentors by 100), and running this like a business. I've written some crappy code that got committed, so I should probably be fired. Enabling our community to be active contributors is an important thing. Give them a means to level up and we'll all be better off from it. ___ 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 6:57 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: But I strongly believe that if we want to do the right thing for the long term, we should switch to GitHub. Encouraging a software, or social, monopoly is never the right thing for the long term. http://nedbatchelder.com/blog/201405/github_monoculture.html I don’t think this is really all that big of a deal. If we want to move off of Github doing so is easy. There are lots of (not nearly as good as but probably still better than what we have now) OSS software that gives you a github like flow. The only *data* that is really in there is what’s stored in the repository itself (since I don’t think for anything major we’d ever put issues there or use the wiki) which is trivial to move around. --- 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano st...@pearwood.info
wrote:
On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:
But I strongly believe that if we want to do the right thing for the
long term, we should switch to GitHub.
Encouraging a software, or social, monopoly is never the right thing for
the long term.
http://nedbatchelder.com/blog/201405/github_monoculture.html
I promise you that once the pain of the switch is over you will feel
much better about it. I am also convinced that we'll get more
contributions this way.
I'm sure that we'll get *more* contributions, but will they be *better*
contributions?
I know that there are people who think that mailing lists are old and
passe, and that we should shift discussion to a social media site like
Reddit. If we did, we'd probably get twenty times as many comments, and
the average quality would probably plummet. More is not necessarily a
good thing.
Reddit: Markdown. Edit. Save.
Is this a challenge for software configuration management
and software requirements traceability?
Could this problem be solved by utilizing namespaced URIs to reference
commits
and issues?
In indexing of these repositories, it would be useful to produce JSON-LD
with an appropriate schema for expressing primary
and other repo URIs,
that could be resolved into the appropriate ssh:// URLs
for each particular ascii domain regex.
- [ ] schema.org/SofwareApplication
- [ ] SEON Ontologies
- [ ] Warehouse/PyPi RDFa, JSON-LD
With secondarily productivity-enhancing URI/URL edges between development
artifacts and feedback review cycles being an overall objective for
infrastructure
and devops comprehension:
* Mailing lists, reviews, issues past current and future, documentation
pages, releases
* Indices (is there a sphinx index that could build the PEPs?)
* Reviews (rietveld, issue tracker)
* Issues Past
* Issues Current
* Issues Future
* Docs
* PEPs
* HOWTOs
* {this could be a useful set of types with URIs and current URLs}
When/if a r'#\d+' is referenced, how do the URLs resolve at render time?
When/if a 'r#issue/tracker/uri/{num}' URL is pasted, is there a pingback?
* sphinx extlinks
* https://github.com/lunaryorn/sphinxcontrib-issuetracker
* https://en.wikipedia.org/wiki/Requirements_traceability
___
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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 2:38 PM, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 3:03 PM, Georg Brandl g.bra...@gmx.net wrote: The next point is that there is no easy way to change the target branch of a pull request (on github or bitbucket). People will usually make patches against the master branch unless told differently explicitly, which means that the pull request will also be against the master branch. Which means, close the PR, ask submitter to resubmit against 3.x branch, or do it yourself. This in particular is not really true on Github at least. By default PRs are made against whichever branch you have configured as the default branch in the Github UI. This does default to master but it doesn’t have to be, for instance pip has this configured for the develop branch. Although I think this specific point is moot because if things were on Git it’d probably make the most sense to have the default integration branch be ``master`` just like for the Hg repos they use default. I'm liking the hubflow/gitflow git workflow extensions, where trunk is also develop. There are feature branches, hotfix branches, release branches, etc. # .git/config : prefix: v git hf release start 0.1.0 echo 0.1.0 VERSION.txt git hf release finish 0.1.0 # (merges, release commit message, return to develop) These are some of the most helpful (git) branching diagrams I've ever seen: * https://datasift.github.io/gitflow/IntroducingGitFlow.html * http://www.infoq.com/articles/agile-version-control The support for tagging releases is helpful. (It's possible to host package releases for various platforms as GitHub releases). Even if someone makes a PR against the wrong branch, it “degrades” into essentially the same UX as you have now, you can turn a PR into a patch by adding a .patch or .diff to the end of the PR URL and then you have a patch file. In additional github makes it easy to check out PRs directly with only a minor bit of one time configuration in your local clone. I can checkout any PR by doing ``git checkout pr/1`` (replacing 1 with whatever the number is). Honestly the worst part about someone sending a PR to the wrong branch is it degrades into the same terrible UX that *every* patch has to go through on a hg.python.org repository right now. In this respect, hg mq is tightly integrated, and written in Python. Patch Queue / build system of VCS integration could be helpful. * http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html * http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html I agree that - [ ] Build status displayed on the PR [is an extremely useful feature for a code forge to offer] - [ ] Markdown/ReStructuredText Checkboxes are helpful * GitHub: Issues * BitBucket: PR Task Lists integrated with review. My mouse cursor tends to be near the scroll bar alot, as well. -- https://en.wikipedia.org/wiki/Forge_(software)#Technology https://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities --- 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/wes.turner%40gmail.com -- Wes Turner https://westurner.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 06:08:07PM -0600, Brian Curtin wrote: On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano st...@pearwood.info wrote: I'm sure that we'll get *more* contributions, but will they be *better* contributions? I know that there are people who think that mailing lists are old and passe, and that we should shift discussion to a social media site like Reddit. If we did, we'd probably get twenty times as many comments, and the average quality would probably plummet. More is not necessarily a good thing. If we need to ensure that we're getting better contributions than we are now, then we should be interviewing committers, rejecting newcomers (or the opposite, multiplying core-mentors by 100), and running this like a business. I've written some crappy code that got committed, so I should probably be fired. None of those things are guarenteed to lead to better contributions. The quality of code from the average successful business is significantly lower than that from successful FOSS projects like Python. Interviews just weed out people who are poor interviewees, not poor performers. And any organisation that fires contributors for relatively trivial mistakes like crappy code would soon run out of developers. My point is that increasing the number of contributions is not, in and of itself, a useful aim to have. More contributions is just a means to an end, the end we want is better Python. Enabling our community to be active contributors is an important thing. Give them a means to level up and we'll all be better off from it. Right. But this isn't a feel-good exercise where anyone who wants a Gold Star for contributing gets commit privileges. (That would enable our community to be active contributors too.) Barriers to contribute work two ways: (1) we miss out on good contributions we would want; (2) we also miss out on poor contributions that would just have to be rejected. Enabling more people to contribute increases both. -- 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 07:39:30PM -0500, Donald Stufft wrote: I don’t think this is really all that big of a deal. If we want to move off of Github doing so is easy. There are lots of (not nearly as good as but probably still better than what we have now) OSS software that gives you a github like flow. The only *data* that is really in there is what’s stored in the repository itself (since I don’t think for anything major we’d ever put issues there or use the wiki) which is trivial to move around. Assuming PRs are enabled on the new repo, how will that interact with patch review/the issue tracker? Is the goal here to replace the existing process wholesale in one step? It doesn't seem fair to say that moving to GitHub will be easy unless interrupting every contributor's flow is considered free, or some Rietveld bridge script magically writes itself. The former impacts review bandwidth, the latter infrastructure bandwidth (which already seems quite contended, e.g. given the job board is still MIA). 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 04:49 PM, Nick Coghlan wrote: Moving from self-hosted Mercurial repos to externally hosted Mercurial repos is a low risk change. It reduces maintenance overhead and lowers barriers to external contribution, both without alienating existing contributors by forcing them to change their workflows. If those repos are externally maintained, what kind of assurances will people have that they are talking to the *official* repositories of the PSF owned assets? One of the problem IMHO of the democratization of branches that a dvcs provides is knowing when you are interacting with the official code of the project. In general, more democracy is better, but that needs to be balanced with verifiable reputation. Having branches hosted on python.org gives people that immediately. Having branches hosted on other domains means there's more uncertainty. Even aside from the we should support open source question (which I feel strongly about but acknowledge others have less allegiance to), it must be absolutely clear that there are repositories which we as the Python development community, bless. 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 08:55 AM, Guido van Rossum wrote: - Moving from Hg to Git is a fair amount of one-time work For anyone seriously interested in this, even experimentally, I would highly suggest looking at Eric Raymond's reposurgeon code. You can google it or find it covered in the vast discussions of his conversion of the Emacs repository from bazaar to git. I don't know for a fact that it would handle an hg to git conversion, but it's the most likely candidate for something so complex. There's a lot of similarity in the history of the Emacs and Python repositories, having gone through many previous iterations of vcs's - in Python's case, at least cvs, svn, and hg. 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 03:59 PM, Nick Coghlan wrote: The learning curve on git is still awful What I find so ironic is that git's model is beautifully simple, but its cli is abysmal, and its manpages are less than helpful. git-push(1) is over 650 lines and it's nearly impossible to dig out the most important bits. 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] Move selected documentation repos to PSF BitBucket account?
git-push(1) is over 650 lines and it's nearly impossible to dig out the most important bits. I use git daily at work. I try to use it in the most simple way possible. My frustration with the man pages got to the point where I basically use Google to ask my questions, then bookmark the solutions I find (which often turn out to be on stackoverflow). Skip ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sunday, November 23, 2014, Skip Montanaro skip.montan...@gmail.com wrote: git-push(1) is over 650 lines and it's nearly impossible to dig out the most important bits. I use git daily at work. I try to use it in the most simple way possible. My frustration with the man pages got to the point where I basically use Google to ask my questions, then bookmark the solutions I find (which often turn out to be on stackoverflow). Then there's this. http://git-man-page-generator.lokaltog.net/ -- --Guido van Rossum (on iPad) ___ 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] Move selected documentation repos to PSF BitBucket account?
On Mon, Nov 24, 2014 at 2:42 PM, Guido van Rossum gu...@python.org wrote: Then there's this. http://git-man-page-generator.lokaltog.net/ Wow scarily accurate. http://git-man-page-generator.lokaltog.net/#2d1a13476a5f32c4db27fd7aa89a84f3 Anything to do with git submodules is virtually impossible to distinguish from an elaborate practical joke. I know this because I have tried to use them. But there is hope: the git maintainers *do* accept docs patches. https://www.kernel.org/pub/software/scm/git/docs/git-config.html#_configuration_file Formerly, this said You will find a description of non-core porcelain configuration variables in the respective porcelain documentation in the appropriate manual page.. Did you know that that means it's acceptable for a third-party git hook to make use of 'git config' to allow end users to configure it? Neither did I, till I asked on the mailing list. However, there are enough git front-ends and tutorials that mean you can generally ignore the man pages until you need something more complicated. Basically, consider the git man pages at the same time you'd consider enabling a Mercurial extension. That's how it seems to be. 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] Move selected documentation repos to PSF BitBucket account?
Brett Cannon writes: How do other projects tend to manage their bugfix vs. in-dev branches? Emacs uses a similar workflow to Python's current one, AIUI: 1. When feasible, developer decides the lowest applicable branch (in Emacs there are only two), commits and pushes there. 2. When needed, merge forward to trunk, supported by a script that helps manage already cherry-picked from trunk and not suitable for trunk patches. Is it a lot of cherrypicking? For Emacs, not that much. Most feature development occurs on trunk, and rarely are commits to trunk considered appropriate for cherrypicking to stable. Most bugfixing is in response to reports on stable, or quickly confirmed to apply to stable, is handled in stable, and then merged forward manually. Probably our long development cycles doesn't help with this as it makes cross-branch merging difficult thanks to divergence, I suspect that the time from bug injection to bug discovery, which is primarily related to length of support commitment, is more relevant than the length of the development cycle. ___ 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] Move selected documentation repos to PSF BitBucket account?
On 24 November 2014 at 02:55, Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan ncogh...@gmail.com wrote: Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. I guess my question is who and what is going to be disrupted if we go with Guido's suggestion of switching to GitHub for code hosting? Contributors won't be disrupted at all since most people are more familiar with GitHub vs. Bitbucket (how many times have we all heard the fact someone has even learned Mercurial just to contribute to Python?). Core developers might be based on some learned workflow, but I'm willing to bet we all know git at this point (and for those of us who still don't like it, myself included, there are GUI apps to paper over it or hg-git for those that prefer a CLI). Our infrastructure will need to be updated, but how much of it is that hg-specific short of the command to checkout out the repo? Obviously Bitbucket is much more minor by simply updating just a URL, but changing `hg clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or someone in the infrastructure committee. Are you volunteering to write a competing PEP for a migration to git and GitHub? I won't be updating PEP 474 to recommend moving to either, as I don't think that would be a good outcome for the Python ecosystem as a whole. It massively undercuts any possible confidence anyone else might have in Mercurial, BitBucket, Rhodecode, Kallithea Allura (all Python based version control, or version control hosting, systems). If we as the Python core development team don't think any of those are good enough to meet the modest version control needs of our support repos, why on earth would anyone else choose them? In reality, I think most of these services are pretty interchangeable - GitHub's just been the most effective at the venture capital powered mindshare grab business model (note how many of the arguments here stem from the fact folks like *other* things that only interoperate with GitHub, and no other repository hosting providers - that's the core of the A18z funded approach to breaking the D in DVCS and ensuring that GitHub's investors are in a position to clip the ticket when GitHub eventually turns around and takes advantage of its dominant market position to increase profit margins). That's why I consider it legitimate to treat supporting fellow Python community members as the determining factor - a number of the available options meet the good enough bar from a technical perspective, so it's reasonable to take other commercial and community factors into account when making a final decision. Probably the biggest thing I can think of that would need updating is our commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would be to update those hooks. If CPython eventually followed suit in migrating to git (as seems inevitable if all the other repos were to switch), then every buildbot will also need to be updated to have git installed (and Mercurial removed). From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. That's not entirely true. If you are pushing a PR shift in our patch acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of benefit, and I would honestly argue that GitHub's PR experience is better. IOW either platform is of equal benefit. Yes, I agree any real benefit comes from the PR workflow, not from git. This is why I consider written in Python to be a valid determining factor - multiple services meet the good enough bar from a practical perspective, allowing other considerations to come to the fore. (Also note that this proposal does NOT currently cover CPython itself. Neither GitHub nor BitBucket is set up to handle maintenance branches well, and any server side merge based workflow improvements for CPython are gated on fixing the NEWS file maintenance issue. However, once you contemplate moving CPython, then the ripple effects on other systems become much larger) It's also worth keeping in mind that changing the underlying VCS means changing *all* the automation scripts, rather than just updating the configuration settings to reflect a new hosting URL. What are the automation scripts there are that would
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On 24 November 2014 at 06:42, Brett Cannon br...@python.org wrote: On Sun Nov 23 2014 at 3:04:05 PM Georg Brandl g.bra...@gmx.net wrote: As for typo fixes, the world does not end when some typos aren't fixed. Anyway, for the docs we have an explicit offer to send anything, patch or just suggestion, to d...@python.org, and people do make use of it. No github account even required. Which is great, but I'm willing to bet clicking Edit in GitHub is easier still than creating the patch and emailing it. I have contributed doc fixes to a bunch of projects because of that Edit button (which is why I think Nick is so anxious to get it). If I had to do any checkout then I wouldn't have done them. And even having to email a diff might be too much for some changes. Yes, it's the ease of noticing a typo or other small, easy to fix error in docs, going to the source page, hitting Edit, and submitting the PR that I like with the online editing support. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On 22 Nov 2014 07:37, Donald Stufft don...@stufft.io wrote: On Nov 21, 2014, at 3:59 PM, Ned Deily n...@acm.org wrote: Sure, I get that. But we're not even talking here about the main Python docs since they are part of the CPython repos, only ancillary repos like PEPs and the developer's guide. The level of activity on those is quite small. So, thinking about it a bit more, PEPs don't normally have bug tracker issues associated with them so I suppose my concerns about issue tracker aren't a major concern for them. The dev guide does get issues opened about it and I suppose they could be managed. But, without tackling the CPython repo workflow (a *much* bigger deal), is the divergence in workflows worth it? I dunno. I also think the tutorial and howto guides should be broken out of the main CPython repo made version independent (with internal version specific notes). That offers no compelling advantages right now, but becomes far more beneficial if it comes with a switch to enabling online editing. Yea for the smaller repositories I don’t have a whole lot of opinion about if the benefit buys us much, especially since one of the goals is new-person friendliness but the problem is that it doesn’t translate to contributing to CPython itself. OK, different question. Has anyone here actually even *read* the workflow PEPs I wrote? They were on the agenda for the language summit, but got bumped due to lack of time (which I'm still annoyed about, given the comparatively inconsequential things that chewed up a whole lot of the day). I've only had a couple of folks from outside the core dev community express interest in them. Personally, the lack of online editing support annoys me immensely whenever I need to work on PEPs or the devguide. I also think it's ridiculous that we have dozens (hundreds?) of folks running community workshops, and all creating their own custom documentation, rather than us finding a way to better enable their collaboration on the official tutorial. The BitBucket proposal in this thread came out of a desire to avoid adding yet more work to an understaffed group of primarily volunteers maintaining the infrastructure (the paid admins are more focused on incident response and general infrastructure support, rather than spinning up new workflow services). My preferred answer remains setting up a srlf-hosted forge.python.org, but I've seen little evidence we have the capacity to deploy maintain such a service effectively, given the relative lack of interest shown in the idea by almost everyone I've spoken to about it. Any progress has only come with a lot of pushing from me, and I just don't have the personal bandwidth to sustain that at this point. That's why the related PEPs were deferred, and the only responses I've received regarding potentially taking them over have come from folks outside the core development community, which really doesn't help very much in removing my availability as a bottleneck in the workflow improvement process. If nobody wants to maintain a self-hosted forge, or even enable the folks that have expressed interest in setting it up maintaining it, then the right answer is don't do it - we should use a commercial service instead. Regards, Nick. --- 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/ncoghlan%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] Move selected documentation repos to PSF BitBucket account?
On Sun, 23 Nov 2014 00:59:42 +1000, Nick Coghlan ncogh...@gmail.com wrote: OK, different question. Has anyone here actually even *read* the workflow PEPs I wrote? They were on the agenda for the language summit, but got bumped due to lack of time (which I'm still annoyed about, given the comparatively inconsequential things that chewed up a whole lot of the day). I have (but I'm core). It's been a while, though, I need to review it. I've only had a couple of folks from outside the core dev community express interest in them. Personally, the lack of online editing support annoys me immensely whenever I need to work on PEPs or the devguide. I also think Eh, I hate online editing ;). But I understand its utility. [...] My preferred answer remains setting up a srlf-hosted forge.python.org, but I've seen little evidence we have the capacity to deploy maintain such a service effectively, given the relative lack of interest shown in the idea by almost everyone I've spoken to about it. Any progress has only come with a lot of pushing from me, and I just don't have the personal bandwidth to sustain that at this point. That's why the related PEPs were deferred, and the only responses I've received regarding potentially taking them over have come from folks outside the core development community, which really doesn't help very much in removing my availability as a bottleneck in the workflow improvement process. If nobody wants to maintain a self-hosted forge, or even enable the folks that have expressed interest in setting it up maintaining it, then the right answer is don't do it - we should use a commercial service instead. I have an interest in this, but like you lack bandwidth. I have no employer that I could petition for 50% open source time, so any time I spend on it is time I'm not billing...so my available time comes and goes depending on my client situation, and I'm also one of the few putting any time in on tracker maintenance (not that I have much lately, Ezio has done most of it) and I've still got the email docs to finish up as well as a list of bugs...yeah, bandwidth is a problem. But maybe I can take over coordination of the volunteers that want to work on the forge. We've already got the mailing list set up. --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] Move selected documentation repos to PSF BitBucket account?
On Nov 22, 2014, at 9:59 AM, Nick Coghlan ncogh...@gmail.com wrote: On 22 Nov 2014 07:37, Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: On Nov 21, 2014, at 3:59 PM, Ned Deily n...@acm.org mailto:n...@acm.org wrote: Sure, I get that. But we're not even talking here about the main Python docs since they are part of the CPython repos, only ancillary repos like PEPs and the developer's guide. The level of activity on those is quite small. So, thinking about it a bit more, PEPs don't normally have bug tracker issues associated with them so I suppose my concerns about issue tracker aren't a major concern for them. The dev guide does get issues opened about it and I suppose they could be managed. But, without tackling the CPython repo workflow (a *much* bigger deal), is the divergence in workflows worth it? I dunno. I also think the tutorial and howto guides should be broken out of the main CPython repo made version independent (with internal version specific notes). That offers no compelling advantages right now, but becomes far more beneficial if it comes with a switch to enabling online editing. Yea for the smaller repositories I don’t have a whole lot of opinion about if the benefit buys us much, especially since one of the goals is new-person friendliness but the problem is that it doesn’t translate to contributing to CPython itself. OK, different question. Has anyone here actually even *read* the workflow PEPs I wrote? They were on the agenda for the language summit, but got bumped due to lack of time (which I'm still annoyed about, given the comparatively inconsequential things that chewed up a whole lot of the day). I've only had a couple of folks from outside the core dev community express interest in them. Personally, the lack of online editing support annoys me immensely whenever I need to work on PEPs or the devguide. I also think it's ridiculous that we have dozens (hundreds?) of folks running community workshops, and all creating their own custom documentation, rather than us finding a way to better enable their collaboration on the official tutorial. The BitBucket proposal in this thread came out of a desire to avoid adding yet more work to an understaffed group of primarily volunteers maintaining the infrastructure (the paid admins are more focused on incident response and general infrastructure support, rather than spinning up new workflow services). My preferred answer remains setting up a srlf-hosted forge.python.org http://forge.python.org/, but I've seen little evidence we have the capacity to deploy maintain such a service effectively, given the relative lack of interest shown in the idea by almost everyone I've spoken to about it. Any progress has only come with a lot of pushing from me, and I just don't have the personal bandwidth to sustain that at this point. That's why the related PEPs were deferred, and the only responses I've received regarding potentially taking them over have come from folks outside the core development community, which really doesn't help very much in removing my availability as a bottleneck in the workflow improvement process. If nobody wants to maintain a self-hosted forge, or even enable the folks that have expressed interest in setting it up maintaining it, then the right answer is don't do it - we should use a commercial service instead. I think I told you before, but if not I’ll say it now :) From the infrastructure side spinning up a new VM is pretty easy, what we need is someone to write some salt states in the psf-salt repository that will deploy an instance of whatever software. I don't have time to figure out the intracities of the various software and deploy them but I can help with figuring out our infra layout. The other thing the infrastructure side would need is some guidance on what size/flavor of Rackspace VM it needs and what additional services it would need (we have a PostgreSQL database already, does it need extra disk space? A Queue? Object Store?). There is a more or less working vagrant setup in the psf-salt[1] repository (a few of the roles don't work yet without manual configuration, like the hg role) but for what someone would need for setting up a new service it should all be there. I'm not sure what else we can do to enable someone who *does* want to work on it to be able to set it up. However I'm not against using a commerical service for smaller repositories. It's fine with me, I don't have a big opinion one way or the other other than I greatly prefer Github over Bitbucket. [1] https://github.com/python/psf-salt --- 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:
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Sat Nov 22 2014 at 10:00:03 AM Nick Coghlan ncogh...@gmail.com wrote: On 22 Nov 2014 07:37, Donald Stufft don...@stufft.io wrote: On Nov 21, 2014, at 3:59 PM, Ned Deily n...@acm.org wrote: Sure, I get that. But we're not even talking here about the main Python docs since they are part of the CPython repos, only ancillary repos like PEPs and the developer's guide. The level of activity on those is quite small. So, thinking about it a bit more, PEPs don't normally have bug tracker issues associated with them so I suppose my concerns about issue tracker aren't a major concern for them. The dev guide does get issues opened about it and I suppose they could be managed. But, without tackling the CPython repo workflow (a *much* bigger deal), is the divergence in workflows worth it? I dunno. I also think the tutorial and howto guides should be broken out of the main CPython repo made version independent (with internal version specific notes). That offers no compelling advantages right now, but becomes far more beneficial if it comes with a switch to enabling online editing. Yea for the smaller repositories I don’t have a whole lot of opinion about if the benefit buys us much, especially since one of the goals is new-person friendliness but the problem is that it doesn’t translate to contributing to CPython itself. OK, different question. Has anyone here actually even *read* the workflow PEPs I wrote? They were on the agenda for the language summit, but got bumped due to lack of time (which I'm still annoyed about, given the comparatively inconsequential things that chewed up a whole lot of the day). I did and was looking forward to them coming to fruition. I've only had a couple of folks from outside the core dev community express interest in them. Personally, the lack of online editing support annoys me immensely whenever I need to work on PEPs or the devguide. I also think it's ridiculous that we have dozens (hundreds?) of folks running community workshops, and all creating their own custom documentation, rather than us finding a way to better enable their collaboration on the official tutorial. The BitBucket proposal in this thread came out of a desire to avoid adding yet more work to an understaffed group of primarily volunteers maintaining the infrastructure (the paid admins are more focused on incident response and general infrastructure support, rather than spinning up new workflow services). My preferred answer remains setting up a srlf-hosted forge.python.org, but I've seen little evidence we have the capacity to deploy maintain such a service effectively, given the relative lack of interest shown in the idea by almost everyone I've spoken to about it. Any progress has only come with a lot of pushing from me, and I just don't have the personal bandwidth to sustain that at this point. That's why the related PEPs were deferred, and the only responses I've received regarding potentially taking them over have come from folks outside the core development community, which really doesn't help very much in removing my availability as a bottleneck in the workflow improvement process. If nobody wants to maintain a self-hosted forge, or even enable the folks that have expressed interest in setting it up maintaining it, then the right answer is don't do it - we should use a commercial service instead. There are two goals to any improvement to the development workflow: that which helps the core devs and that which helps everyone else. For helping core devs that's getting some CI set up which will test every patch submitted, single-click patch committal from the issue tracker, etc. For everyone else it's inline editing and whatever it takes to get patches accepted faster (I know Nick is pointing out he wants inline editing for PEPs and docs but I don't view that as critical for core devs who already have the checkouts available and have the workflow memorized). From my perspective, getting our commit workflow improved is the critical first step before we worry about making it easier to receive patches. If we can't keep up with an influx of patches that might occur from inline editing then there is little point in having it; frustrating people that we can't commit patches as fast as we receive them is not helpful. Now in terms of how the heck we are ever going to improve our workflow, that's tricky. As Nick as pointed out we are low on volunteer time. Take the issue tracker as an example: Ezio Melotti does a large amount of work and R. David Murray also helps, but that's mostly it (Martin von Löwis has helped in the past but has been mostly absent as of late). We are not well covered in the hit by a bus scenario. I understand the viewpoint of not wanting to give up control of our process to a third party, and I understand not wanting to use closed-source software. But at some point there is a practicality beats
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. -- --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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 12:19 AM, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Heck I am a Core dev technically and I setup a git repo first until it’s moved into the hg.python.org http://hg.python.org/. --- 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] Move selected documentation repos to PSF BitBucket account?
re: docs hg repos and static HTTP hosting * I can't remember what the GitHub Pages CDN cache time is * Does BitBucket support more than one pages repo? * Does service X support Sphinx .. index and :ref: syntax extensions? * https://github.com/yoloseem/awesome-sphinxdoc * https://github.com/rtfd/readthedocs.org (hostthedocs) * http://conf.writethedocs.org/ * https://docs.python.org/devguide/documenting.html On Sat, Nov 22, 2014 at 11:19 PM, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. -- --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/wes.turner%40gmail.com -- Wes Turner https://westurner.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On 23 November 2014 at 15:19, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 15:19, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). It does have one very big compelling advantage. It’s way more popular. Besides, the learning curve on hg isn’t any better, it’s just differently hard. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Going to all the trouble to move to an external repository and choosing the least popular option out of the two main ones seems like a bad idea in general. --- 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 1:03 AM, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 15:19, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). It does have one very big compelling advantage. It’s way more popular. Besides, the learning curve on hg isn’t any better, it’s just differently hard. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Going to all the trouble to move to an external repository and choosing the least popular option out of the two main ones seems like a bad idea in general. Also important to note, that if people want to use hg on their own, it’s pretty easy to do that with https://hg-git.github.io/. Last I heard that works pretty well still. I’ve yet to find one that works the other direction that doesn’t choke on some repositories. --- 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote: The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). The learning curve for source control as a concept is pretty steep. Once someone's learned one DVCS, learning another is much easier, and I don't know that it makes a lot of difference whether you learn git and then hg, or hg and then git. I learned git first, and mastered hg basics by keeping a Rosetta Stone chart handy; given that the document I was reading was intended for the reverse case, I expect it's not too hard to get the basics of git once you know hg. Just as git offers few advantages over hg, hg offers few advantages over git. If git and GitHub are where most people are, I would support using them for Python. I'm one of those PEP draft authors who starts with his own repo on GitHub and sends drafts in, and Guido had to remind me that I can simply test my edits in the peps repo before posting them (to make sure I haven't mucked up the markup); if the peps repo were itself hosted on GitHub, or at least in a git repo, I could have a workflow that directly incorporates that, instead of being off to the side with periodic manual imports. That said, it does make sense for CPython *itself* to use Mercurial, simply because it's written in Python. I don't know how strong that philosophical argument is with people, but I wouldn't argue against it. 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] Move selected documentation repos to PSF BitBucket account?
On Saturday, November 22, 2014, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 15:19, Guido van Rossum gu...@python.org javascript:; wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). Git may well have a learning curve, but ever since I got it I started preferring it over hg. Too bad for BitBucket, but most people who started contributing to open source in the past 5 years already have a GitHub account. Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. What about potential new contributors? And the hg-git bridges that git fans are always referred to work in the opposite direction too... :-) -- --Guido van Rossum (on iPad) ___ 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] Move selected documentation repos to PSF BitBucket account?
The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). This was a most helpful resource: https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone Wikipedia: https://en.wikipedia.org/wiki/Git_(software) Homepage: http://git-scm.com/ Docs: http://git-scm.com/documentation Docs: http://git-scm.com/book/en/ Docs: http://documentup.com/skwp/git-workflows-book Docs: http://learnxinyminutes.com/docs/git/ Source: git https://github.com/git/git hg imuutability is certainly a primarily attractive feature; along with the keyring support. On Sat, Nov 22, 2014 at 11:59 PM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 15:19, Guido van Rossum gu...@python.org wrote: This thread seems to beg for a decision. I think Donald Stufft has it exactly right: we should move to GitHub, because it is the easiest to use and most contributors already know it (or are eager to learn thee). Honestly, the time for core devs (or some other elite corps of dedicated volunteers) to sysadmin their own machines (virtual or not) is over. We've never been particularly good at this, and I don't see us getting better or more efficient. The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). Moving the CPython code and docs is not a priority, but everything else (PEPs, HOWTOs etc.) can be moved easily and I am in favor of moving to GitHub. For PEPs I've noticed that for most PEPs these days (unless the primary author is a core dev) the author sets up a git repo first anyway, and the friction of moving between such repos and the official repo is a pain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Cheers, 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/wes.turner%40gmail.com -- Wes Turner https://westurner.github.io/ ___ 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] Move selected documentation repos to PSF BitBucket account?
On 23 November 2014 at 16:03, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Going to all the trouble to move to an external repository and choosing the least popular option out of the two main ones seems like a bad idea in general. Moving repos from hg.python.org to bitbucket.org is just a matter of switching some URLs around, and changing some backend systems to cope with the new location. The end result should be to make life better for existing contributors *and* new contributors using the web UI, and be largely transparent to folks using command line tools. By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. That significant increase in the time investment required will provide *NO* practical benefit for existing contributors (this is coming from someone that has used git and Mercurial in parallel for years - trust me, they're functionally isomorphic), and only make life marginally easier for potential new contributors (you can log in to BitBucket with your GitHub ID, and the functional isomorphism means that many folks already use tools like git-remote-hg to use the git command line to interact with the hg.python.org Mercurial repos). 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 1:25 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 16:03, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Going to all the trouble to move to an external repository and choosing the least popular option out of the two main ones seems like a bad idea in general. Moving repos from hg.python.org to bitbucket.org is just a matter of switching some URLs around, and changing some backend systems to cope with the new location. The end result should be to make life better for existing contributors *and* new contributors using the web UI, and be largely transparent to folks using command line tools. By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. That significant increase in the time investment required will provide *NO* practical benefit for existing contributors (this is coming from someone that has used git and Mercurial in parallel for years - trust me, they're functionally isomorphic), and only make life marginally easier for potential new contributors (you can log in to BitBucket with your GitHub ID, and the functional isomorphism means that many folks already use tools like git-remote-hg to use the git command line to interact with the hg.python.org Mercurial repos). Yea, but then you lose out on the entire ecosystem built around Github. Like you won’t be able to run travis tests on the docs to make sure that any Pull Requests don’t silently start breaking the ability to build the docs. --- 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 5:03 PM, Wes Turner wes.tur...@gmail.com wrote: hg imuutability is certainly a primarily attractive feature; along with the keyring support. What exactly do you mean by immutability? Are you talking about how git allows a force push that can destroy data? That can be rejected in a repo's hook scripts; also, I'm fairly sure I remember reading somewhere about how to do that with hg, too. It's all bits of data inside computers; nothing's immutable. Both DVCSes pledge to make it obvious any time something is altered, not to make it impossible to alter. 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] Move selected documentation repos to PSF BitBucket account?
On 23 November 2014 at 16:10, Guido van Rossum gu...@python.org wrote: On Saturday, November 22, 2014, Nick Coghlan ncogh...@gmail.com wrote: The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). Git may well have a learning curve, but ever since I got it I started preferring it over hg. I took the git knowledge I acquired by necessity at Red Hat and figured out how to apply it to hg. All the same features are there in hg, they're just switched off by default (mainly because the core Mercurial devs are adamant that any potentially history destroying operation in a version control system must be opt-in). In particular, the evolve extension is an impressive tool that allows history to be edited in such a way that the edits can be safely shared amongst repos. Too bad for BitBucket, but most people who started contributing to open source in the past 5 years already have a GitHub account. You can log into BitBucket with a GitHub account. More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. What about potential new contributors? And the hg-git bridges that git fans are always referred to work in the opposite direction too... :-) We already have lots of potential contributors (if we didn't, review bandwidth wouldn't be the bottleneck the way it is today), and the functional differences between GitHub and BitBucket from a barrier to entry perspective are so low as to be trivial. For organisations with no vested interest in BitBucket or Mercurial, sure, they may as well just go with the popular choice. Unlike most organisations, we have a vested interest in encouraging the growth of the Python ecosystem and community, and the developers of both Mercurial and BitBucket are members of that community. While we have historically done very little to date in reaching out to the Mercurial developers and seek their assistance in improving the developer guide, remedying that and providing better Mercurial usage guidelines is one of my hoped for outcomes in making it easier for others to contribute to the developer guide. By contrast, GitHub is a Ruby application, and git is a collection of C and shell scripts - they may be tools used *by* the Python community, but they are decidedly not products *of* the Python community. Given the choice between two functionally equivalent solutions, one of which lets us continue using the tools we already use (including all the associated automation), and is created by members of the same development community, I think the burden of proof falls on the folks that want to make the backwards incompatible change that the additional cost will be worth it. Moving from self-hosted Mercurial repos to externally hosted Mercurial repos is a low risk change. It reduces maintenance overhead and lowers barriers to external contribution, both without alienating existing contributors by forcing them to change their workflows. Proposing to *also* switch from Mercurial to git significantly increases the cost of the change, while providing minimal incremental benefit. 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] Move selected documentation repos to PSF BitBucket account?
On 23 November 2014 at 16:27, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 1:25 AM, Nick Coghlan ncogh...@gmail.com wrote: By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. That significant increase in the time investment required will provide *NO* practical benefit for existing contributors (this is coming from someone that has used git and Mercurial in parallel for years - trust me, they're functionally isomorphic), and only make life marginally easier for potential new contributors (you can log in to BitBucket with your GitHub ID, and the functional isomorphism means that many folks already use tools like git-remote-hg to use the git command line to interact with the hg.python.org Mercurial repos). Yea, but then you lose out on the entire ecosystem built around Github. Like you won’t be able to run travis tests on the docs to make sure that any Pull Requests don’t silently start breaking the ability to build the docs. Travis isn't the only CI system on the internet, and for pure Sphinx documentation cases, ReadTheDocs runs just as well off BitBucket as it does off GitHub. I personally think changing version control systems would be an incredibly bad idea, and consider it completely out of scope for discussions of Mercurial repo hosting arrangements. There's a lot that could be done, with much lower impact, just by changing the way we manage the existing Mercurial repos. When we can't even work out the practical details of getting those implemented, suggestions of git/GitHub will fix it! sound like mere wishful thinking. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 1:49 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 16:10, Guido van Rossum gu...@python.org wrote: On Saturday, November 22, 2014, Nick Coghlan ncogh...@gmail.com wrote: The learning curve on git is still awful - it offers no compelling advantages over hg, and GitHub doesn't offer any huge benefits over BitBucket for Sphinx based documentation (ReadTheDocs works just as well with either service). Git may well have a learning curve, but ever since I got it I started preferring it over hg. I took the git knowledge I acquired by necessity at Red Hat and figured out how to apply it to hg. All the same features are there in hg, they're just switched off by default (mainly because the core Mercurial devs are adamant that any potentially history destroying operation in a version control system must be opt-in). In particular, the evolve extension is an impressive tool that allows history to be edited in such a way that the edits can be safely shared amongst repos. Often times it’s there multiple times in different incompatible ways so figuring out which extension to use can be hard. They also have varying levels of compatibility with other tools. Setuptools uses “bookmarks” instead of branches sometimes and that confuses bitbucket in some way that makes bitbucket throw errors at me when I attempt to use it. I’ve not had much luck personally with the extensions to Hg, they seem to be second class citizens in terms of workflow and I do think that them being off by default makes them worse too. Too bad for BitBucket, but most people who started contributing to open source in the past 5 years already have a GitHub account. You can log into BitBucket with a GitHub account. More generally, I'm very, very disappointed to see folks so willing to abandon fellow community members for the sake of following the crowd. Perhaps we should all just abandon Python and learn Ruby or JavaScript because they're better at getting press in Silicon Valley? I don’t think this is really fair. It’s not about press, it’s about the best tool for the job and being pragmatic. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. What about potential new contributors? And the hg-git bridges that git fans are always referred to work in the opposite direction too... :-) We already have lots of potential contributors (if we didn't, review bandwidth wouldn't be the bottleneck the way it is today), and the functional differences between GitHub and BitBucket from a barrier to entry perspective are so low as to be trivial. That’s not really true. It’s more than just “can I log in”, potential contributors are more likely to already know how to use Github too and are more likely to not want to deal with another site. I know personally if I see a project is on bitbucket my chances of contributing to that project drop drastically, even if they are using git on bitbucket, just because I know that I’m going to get frustrated to some degree. For organisations with no vested interest in BitBucket or Mercurial, sure, they may as well just go with the popular choice. Unlike most organisations, we have a vested interest in encouraging the growth of the Python ecosystem and community, and the developers of both Mercurial and BitBucket are members of that community. While we have historically done very little to date in reaching out to the Mercurial developers and seek their assistance in improving the developer guide, remedying that and providing better Mercurial usage guidelines is one of my hoped for outcomes in making it easier for others to contribute to the developer guide. By contrast, GitHub is a Ruby application, and git is a collection of C and shell scripts - they may be tools used *by* the Python community, but they are decidedly not products *of* the Python community. Well CPython is a C application so perhaps we should switch to an interpreter written in Python if the goal is to always pick the thing that’s written in Python? Given the choice between two functionally equivalent solutions, one of which lets us continue using the tools we already use (including all the associated automation), and is created by members of the same development community, I think the burden of proof falls on the folks that want to make the backwards incompatible change that the additional cost will be worth it. Moving from self-hosted Mercurial repos to externally hosted Mercurial repos is a low risk change. It reduces maintenance overhead and lowers barriers to external contribution, both without alienating existing contributors by forcing them to change their workflows. Proposing to *also* switch from Mercurial to git significantly increases the cost of the change, while providing minimal incremental benefit. Regards,
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Nov 23, 2014, at 2:01 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 November 2014 at 16:27, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 1:25 AM, Nick Coghlan ncogh...@gmail.com wrote: By contrast, proposals to switch from Mercurial to Git impose a *massive* burden on contributors that don't already know git. That significant increase in the time investment required will provide *NO* practical benefit for existing contributors (this is coming from someone that has used git and Mercurial in parallel for years - trust me, they're functionally isomorphic), and only make life marginally easier for potential new contributors (you can log in to BitBucket with your GitHub ID, and the functional isomorphism means that many folks already use tools like git-remote-hg to use the git command line to interact with the hg.python.org Mercurial repos). Yea, but then you lose out on the entire ecosystem built around Github. Like you won’t be able to run travis tests on the docs to make sure that any Pull Requests don’t silently start breaking the ability to build the docs. Travis isn't the only CI system on the internet, and for pure Sphinx documentation cases, ReadTheDocs runs just as well off BitBucket as it does off GitHub. Sure it’s not the only CI system, but as far as I know bitbucket doesn’t have near the integration possible with CI systems. I make a PR on github I get it tested and the merge button turns green to let me know that the tests run. Travis is popular enough that I’ve seen bitbucket projects hosting a mirror on github *just* for travis. I personally think changing version control systems would be an incredibly bad idea, and consider it completely out of scope for discussions of Mercurial repo hosting arrangements. There's a lot that could be done, with much lower impact, just by changing the way we manage the existing Mercurial repos. When we can't even work out the practical details of getting those implemented, suggestions of git/GitHub will fix it! sound like mere wishful thinking. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- 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] Move selected documentation repos to PSF BitBucket account?
On 23 November 2014 at 17:14, Donald Stufft don...@stufft.io wrote: On Nov 23, 2014, at 2:01 AM, Nick Coghlan ncogh...@gmail.com wrote: Travis isn't the only CI system on the internet, and for pure Sphinx documentation cases, ReadTheDocs runs just as well off BitBucket as it does off GitHub. Sure it’s not the only CI system, but as far as I know bitbucket doesn’t have near the integration possible with CI systems. I make a PR on github I get it tested and the merge button turns green to let me know that the tests run. Travis is popular enough that I’ve seen bitbucket projects hosting a mirror on github *just* for travis. In the absence of a proposal to change version control systems (again), the lack of Mercurial hosting on GitHub makes it rather a moot point. Given that we can barely muster up any enthusiasm for rehosting *without* changing version control systems (and the number of CI systems that integrate with hg.python.org repos other than the main CPython one is exactly zero), any proposal that involves doing even *more* work seems doubly doomed. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan ncogh...@gmail.com wrote: For those that aren't aware, PEP 474 is a PEP I wrote a while back suggesting we set up a forge.python.org service that provides easier management of Mercurial repos that don't have the complex branching requirements of the main CPython repo. Think repos like the PEPs repo, or the developer guide repo. The primary objective of the PEP is to enable an online editing + pull request style workflow for these pure documentation projects that only have a single active branch. I'd been taking must be hosted in PSF infrastructure as a hard requirement, but MAL pointed out earlier this evening that in the age of DVCS's, that requirement may not make sense: if you avoid tightly coupling your automation to a particular DVCS host's infrastructure, then reverting back to self-hosting (if that becomes necessary for some reason) is mostly just a matter of hg push. I don't view self-hosting as ever being a requirement. We hosted ourselves mainly to fully control commit messages (we do like to be very explicit after all =). Because we didn't want to pollute our message log with people's own messages which didn't follow our commit log guidelines or were of high enough caliber, we chose to fully control the hosting so as to not give people a false hope that we would accept a pull request. If that must be self-hosted constraint is removed, then the obvious candidate for Mercurial hosting that supports online editing + pull requests is the PSF's BitBucket account. There's also CodePlex and (ironically) SourceForge for open-source hg hosting. There'd still be some work in such a change to make sure we didn't break automated regeneration of associated site elements, but that's still a lot simpler than adding an entirely new piece of infrastructure. If folks are amenable to that variant of the idea, I'll undefer PEP 474 and revise it accordingly, with the developer guide and the PEP's repo as the initially proposed candidates for transfer. I think showing us how to ignore PR comments and only show those from merges and direct commits on a branch (e.g. blame, reading log output, etc.) would help, i.e. how to work with Mercurial so I only see commit messages from core developers or ones they directly could edit? ___ 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] Move selected documentation repos to PSF BitBucket account?
On 21 November 2014 23:29, Brett Cannon br...@python.org wrote: On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan ncogh...@gmail.com wrote: If that must be self-hosted constraint is removed, then the obvious candidate for Mercurial hosting that supports online editing + pull requests is the PSF's BitBucket account. There's also CodePlex and (ironically) SourceForge for open-source hg hosting. Did SF end up actually integrating Hg hosting properly? They hadn't the last time I looked - it was still a third party addon to Allura. I'll spell this out in the PEP, but the reason I suggest BitBucket in particular is: - it's written in Python - the PSF already has an organisational account set up there - I have admin access, so I can bootstrap other folks as administrators (Christian Heimes Brian Curtin are also admins) - I know the online editing works reliably, since I maintain the PyPI metadata PEP drafts there - having used both it and GitHub extensively, I'm confident the workflows are similar enough that anyone familiar with GitHub will be able to easily pick up the BitBucket UI As far as ignoring PR noise goes, we can still request that folks squash any commits (keep in mind that the proposal is only to move pure documentation repos, so long complex PR chains seem unlikely). Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On 22 November 2014 00:00, Brett Cannon br...@python.org wrote: As far as ignoring PR noise goes, we can still request that folks squash any commits (keep in mind that the proposal is only to move pure documentation repos, so long complex PR chains seem unlikely). Well, requesting that and actually getting it are two different things, especially when I don't know of any way to rewrite a commit message after the fact if we go back to someone and say your commit message is bad, please fix it. Worst case? Ask them to submit a new pull request. Cheers, 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] Move selected documentation repos to PSF BitBucket account?
On Fri Nov 21 2014 at 8:57:15 AM Nick Coghlan ncogh...@gmail.com wrote: On 21 November 2014 23:29, Brett Cannon br...@python.org wrote: On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan ncogh...@gmail.com wrote: If that must be self-hosted constraint is removed, then the obvious candidate for Mercurial hosting that supports online editing + pull requests is the PSF's BitBucket account. There's also CodePlex and (ironically) SourceForge for open-source hg hosting. Did SF end up actually integrating Hg hosting properly? They hadn't the last time I looked - it was still a third party addon to Allura. I'll spell this out in the PEP, but the reason I suggest BitBucket in particular is: - it's written in Python - the PSF already has an organisational account set up there - I have admin access, so I can bootstrap other folks as administrators (Christian Heimes Brian Curtin are also admins) - I know the online editing works reliably, since I maintain the PyPI metadata PEP drafts there - having used both it and GitHub extensively, I'm confident the workflows are similar enough that anyone familiar with GitHub will be able to easily pick up the BitBucket UI You're putting more thought into the response than I did in the suggestion. =) I just know they claim to host hg repos. As far as ignoring PR noise goes, we can still request that folks squash any commits (keep in mind that the proposal is only to move pure documentation repos, so long complex PR chains seem unlikely). Well, requesting that and actually getting it are two different things, especially when I don't know of any way to rewrite a commit message after the fact if we go back to someone and say your commit message is bad, please fix it. ___ 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
