We will be moving to GitHub
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on: 1. No major distinguishing features between GitHub or GitLab 2. Familiarity amongst core devs -- and external contributors -- with GitHub 3. Guido prefers GitHub Neither platform had some mind-blowing feature(s) that really made them stand out from each other such that it would greatly simplify our lives if we chose one platform over another. I obviously was really hoping there was going to be something I missed, but nothing ever came up (and no, being open source is not enough of a feature; as I said when I started this process, being open source would help break ties or minor lead of one tool but not be a deciding factor). But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub. I think most of that stemmed from having used GitHub for other open source projects and/or work, making even dormant core devs say they would be able to become active again if we switched to GitHub thanks to eliminating the barrier of having to keep up with our custom workflow for code reviews and using hg for commits. And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub. And at least for me, the fact Guido prefers GitHub means something. While Guido himself would say I shouldn't really worry about his preferences since he is only an occasional contributor at this point, I believe that it's important that our BDFL actually like contributing to his own programming language rather than potentially alienating him because he finds the process burdensome. So that's why I have chosen GitHub over GitLab. Please realize that this is choosing GitHub to provide repository hosting and code review; we are not moving our issue tracker, nor are we moving our wiki. And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic). Thanks to everyone who contributed to this decision, especially Donald, Barry, and Nick for making the proposals we had to work from. We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :)
Brett Cannon <brett@...> writes:
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
We must have been reading different discussions: On *this* list more people were in favor of GitLab! Except for Guido, Donald and Senthil (on python-committers) no one has even bothered to post an explicit +1 for GitHub. It's very disappointing that GitHub proponents apparently felt the need to contact you privately instead of stating their opinions in the open. Stefan Krah
On Fri, 01 Jan 2016 20:25:11 +0000, Stefan Krah <skrah.temporarily@gmail.com> wrote:
Brett Cannon <brett@...> writes:
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
We must have been reading different discussions: On *this* list more people were in favor of GitLab! Except for Guido, Donald and Senthil (on python-committers) no one has even bothered to post an explicit +1 for GitHub.
It's very disappointing that GitHub proponents apparently felt the need to contact you privately instead of stating their opinions in the open.
The impression I got here was Barry advocating GitLab (of course), and you arguing against GitHub (but not, particularly, in favor of GitLab). Everything else was down at the noise level :) Me, I don't care one way or the other, as long as we aren't locking ourselves in to either. Now, the fact that people felt it better to contact Brett privately to advocate for GitHub is indeed interesting, and yes, disappointing. The interesting question is, why is that? Perhaps it is what was alluded to earlier, that favoring the "commercial alternative" is seen as "bad" in terms of what we might label as "virtue signalling"? Which would be weird, because GitLab isn't non-commercial. So maybe there's some other reason (because GitHub is the big gorilla and people think it is "better" to favor the underdog?), but I wonder if it still comes down to virtue signalling (or, rather, not wanting to signal non-virtue, in this case). So I agree with you, it would be great if people would openly speak their minds, as Guido did :) On the other hand, it might just be a matter of the "usenet nod", and not wanting to "clutter up the list" with a "me too". You did get some pushback against your arguments, to which people may have been nodding. --David
On 2 Jan 2016 07:37, "R. David Murray" <rdmurray@bitdance.com> wrote:
On Fri, 01 Jan 2016 20:25:11 +0000, Stefan Krah <
skrah.temporarily@gmail.com> wrote:
Brett Cannon <brett@...> writes:
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
We must have been reading different discussions: On *this* list more people were in favor of GitLab! Except for Guido, Donald and Senthil (on python-committers) no one has even bothered to post an explicit +1 for GitHub.
It's very disappointing that GitHub proponents apparently felt the need to contact you privately instead of stating their opinions in the open.
The impression I got here was Barry advocating GitLab (of course), and you arguing against GitHub (but not, particularly, in favor of GitLab). Everything else was down at the noise level :)
Me, I don't care one way or the other, as long as we aren't locking ourselves in to either.
Now, the fact that people felt it better to contact Brett privately to advocate for GitHub is indeed interesting, and yes, disappointing. The interesting question is, why is that? Perhaps it is what was alluded to earlier, that favoring the "commercial alternative" is seen as "bad" in terms of what we might label as "virtue signalling"? Which would be weird, because GitLab isn't non-commercial. So maybe there's some other reason (because GitHub is the big gorilla and people think it is "better" to favor the underdog?), but I wonder if it still comes down to virtue signalling (or, rather, not wanting to signal non-virtue, in this case).
So I agree with you, it would be great if people would openly speak their minds, as Guido did :)
On the other hand, it might just be a matter of the "usenet nod", and not wanting to "clutter up the list" with a "me too". You did get some pushback against your arguments, to which people may have been nodding.
--David _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
(Sorry, accidentally hit send while trying to discard a previous draft) On 2 Jan 2016 11:17, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 2 Jan 2016 07:37, "R. David Murray" <rdmurray@bitdance.com> wrote:
Now, the fact that people felt it better to contact Brett privately to advocate for GitHub is indeed interesting, and yes, disappointing. The interesting question is, why is that? Perhaps it is what was alluded to earlier, that favoring the "commercial alternative" is seen as "bad" in terms of what we might label as "virtue signalling"? Which would be weird, because GitLab isn't non-commercial. So maybe there's some other reason (because GitHub is the big gorilla and people think it is "better" to favor the underdog?), but I wonder if it still comes down to virtue signalling (or, rather, not wanting to signal non-virtue, in this case).
Yep, I think that's a large part of it, as the folks funding GitHub are quite open about the fact that they consider centralised US corporate control of the technology industry something to be admired, rather than deplored (See http://techcrunch.com/2014/02/13/please-dont-tell-me-you-want-to-be-the-next... for one of the most explicit examples of that genre). GitLab's business model is different, as it's just a low cost competitor in the self-hosted VCS market that takes advantage of people's familiarity with GitHub's UI, rather than aiming to become the de facto standard for open collaboration infrastructure (with corresponding influence over the career prospects of individual developers). The free software movement has been fighting an underdog battle against that kind of centralised control for 30 years. That hasn't been a stellar success so far, with the likes of Amazon, Google, Facebook, Apple and Microsoft v2.0 now making their predecessors like IBM, Oracle and Microsoft v1.0 look like rank amateurs when it comes to exerting centralised control over the world's computing infrastructure. (Tom Watson's apocryphal prediction of a world market for maybe 5 computers seems likely to come true, it's just that their names will be AWS, Azure, GCE, Aliyun, and SoftLayer). That doesn't explain why folks might be reluctant to state a preference for a proprietary service in public, though. For that, I think we need to account for the fact that the free software movement is often it's own worst enemy, as it tends to be *very* focused on ideological purity, so proprietary dependencies are considered categorically unacceptable in many circles, rather than as risks to be mitigated through pragmatic measures. Trying to explain "We looked the gift horse in the mouth, checked all its teeth, and are happy we can deal with the risks of accepting the gift" can be incredibly draining when you have folks yelling at you that accepting gratis contributions of proprietary software and services mean you don't care about the future of the open source community or about software freedom. I stepped over that line myself back when the GitHub proposal was first put forward, and Guido quite rightly called me on it - I wasn't properly separating my own long term objectives from the immediate interests of the CPython core development community. Since the pro-GitHub perspective was being suitably represented already (and was clearly the default choice, with most of the discussions focusing on "Is there a reason to *not* just use GitHub?"), why *would* anyone want to risk exposing themselves to that kind of potential negative response? Cheers, Nick.
On Fri, 1 Jan 2016 at 13:37 R. David Murray <rdmurray@bitdance.com> wrote:
On Fri, 01 Jan 2016 20:25:11 +0000, Stefan Krah < skrah.temporarily@gmail.com> wrote:
Brett Cannon <brett@...> writes:
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
We must have been reading different discussions: On *this* list more people were in favor of GitLab! Except for Guido, Donald and Senthil (on python-committers) no one has even bothered to post an explicit +1 for GitHub.
It's very disappointing that GitHub proponents apparently felt the need to contact you privately instead of stating their opinions in the open.
The impression I got here was Barry advocating GitLab (of course), and you arguing against GitHub (but not, particularly, in favor of GitLab). Everything else was down at the noise level :)
That's the impression I got as well. The reason I didn't think it would be surprising was my constant prodding for GitLab features that made it stand out. I wouldn't have bothered pushing for that if I had already chosen GitLab or thought it was on track to win out. The fact that I persistently tried to make the open source solution somehow shine was because I was trying to grasp on to something for GitLab because I was trying to avoid the stress of dealing with people being unhappy with selecting GitHub by making my decision glaringly obvious (and in all honesty it would have been nice if an open source solution could have won out; maybe in the future). In the end, though, I decided dealing with people upset from going with GitHub was worth it compared to the positives of selecting GitHub, hence my decision.
Me, I don't care one way or the other, as long as we aren't locking ourselves in to either.
Now, the fact that people felt it better to contact Brett privately to advocate for GitHub is indeed interesting, and yes, disappointing. The interesting question is, why is that? Perhaps it is what was alluded to earlier, that favoring the "commercial alternative" is seen as "bad" in terms of what we might label as "virtue signalling"? Which would be weird, because GitLab isn't non-commercial. So maybe there's some other reason (because GitHub is the big gorilla and people think it is "better" to favor the underdog?), but I wonder if it still comes down to virtue signalling (or, rather, not wanting to signal non-virtue, in this case).
So I agree with you, it would be great if people would openly speak their minds, as Guido did :)
On the other hand, it might just be a matter of the "usenet nod", and not wanting to "clutter up the list" with a "me too". You did get some pushback against your arguments, to which people may have been nodding.
The comments came of two forms. Some were of "yay for GitHub" so basically a one sentence head nod. The other was a few private messages that were a bit longer and explaining their view on the options (including not switching). The vast majority of these emails, though, were in reaction to my email to python-committers asking for people to tell me if they would walk away if we chose GitHub. Most said they were emailing me privately to avoid adding any unnecessary noise to that email thread, but I suspect it also had to do with them not being subscribers to core-workflow and not caring enough to join this list to wade into the discussion. But also realize that this process has been going on for over a year now. I have had multiple conversations at conferences at this point with people who expressed various opinions on the matter and I didn't report those face-to-face conversations either and which are no different than a private email. There was never going to be a chance where anyone but me was going to have complete knowledge of people's various positions, nor was I about to report a tally of those conversations based on preferences. I'm sorry if people feel like I did a disservice by not doing a regular "general sentiment of the Python community" report based on what private feedback I received, but I just didn't think about it nor did I think it would be an issue for anyone that people chose to speak with me privately.
But also realize that this process has been going on for over a year now. I have had multiple conversations at conferences at this point with people who expressed various opinions on the matter and I didn't report those face-to-face conversations either and which are no different than a private email. There was never going to be a chance where anyone but me was going to have complete knowledge of people's various positions, nor was I about to report a tally of those conversations based on preferences. I'm sorry if
Brett Cannon <brett@...> writes: people feel like I did a disservice by not doing a regular "general sentiment of the Python community" report based on what private feedback I received, but I just didn't think about it nor did I think it would be an issue for anyone that people chose to speak with me privately. Thank you for the explanation. It's a bit of a recurring problem here that once something has been discussed at a conference, the people who weren't there have a very hard time to catch up via the mailing lists. So I don't think posting +-1 on python-committers is noise, in matters like this one it should happen more often. Sorry for starting this subthread during your vacation (I missed that), I hope you can enjoy the remaining days! Stefan Krah
First-timer here on this list. Just wanted to chime in briefly on a few things. Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to make the association. No reason we can’t have both, though. But either way we should have a way to connect PRs to issues. I have seen many projects — specifically those using an issue tracker outside of GitHub — accomplish this by asking their contributors to include the issue number in the title. Two example projects doing this: Apache Spark <https://github.com/apache/spark/pulls>, Scala <https://github.com/scala/scala/pulls> Then, those projects would have some kind of bot or hook (like Berker mentioned) use the issue number in the PR title to create a reference over on the issue tracker. For example, here is the script <https://github.com/apache/spark/blob/master/dev/github_jira_sync.py> that the Apache Spark project uses to create links on JIRA (their issue tracker) to PRs. And here is an issue <https://issues.apache.org/jira/browse/SPARK-11744> where you can see the link that was automatically created to the PR referencing it (under “Issue Links”). If we end up using a CI service with good GitHub integration like Travis, we may even be able to use it to create the issue links as part of the build—no bot or separate service required. Additionally, if we want all PRs to include an issue reference, for example, that could be automatically enforced. Any PR without an issue reference in the title would fail that check, which shows up as a nice, clear X on the PR, with a link to more detail. I’ll echo what others have said and say that I too am interested in contributing to Python project infrastructure, especially in the area of CI integration and various types of automation that make the lives of contributors and committers easier. I spent a lot of time doing very similar work for the Apache Spark project. I think it’s an important thing to work on; lower friction enables more people to contribute more often, and that’s very important for the long-term health of the project. Nick
Hi, On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon <brett@python.org> wrote:
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
No major distinguishing features between GitHub or GitLab Familiarity amongst core devs -- and external contributors -- with GitHub Guido prefers GitHub
Neither platform had some mind-blowing feature(s) that really made them stand out from each other such that it would greatly simplify our lives if we chose one platform over another. I obviously was really hoping there was going to be something I missed, but nothing ever came up (and no, being open source is not enough of a feature; as I said when I started this process, being open source would help break ties or minor lead of one tool but not be a deciding factor).
But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub. I think most of that stemmed from having used GitHub for other open source projects and/or work, making even dormant core devs say they would be able to become active again if we switched to GitHub thanks to eliminating the barrier of having to keep up with our custom workflow for code reviews and using hg for commits. And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub.
And at least for me, the fact Guido prefers GitHub means something. While Guido himself would say I shouldn't really worry about his preferences since he is only an occasional contributor at this point, I believe that it's important that our BDFL actually like contributing to his own programming language rather than potentially alienating him because he finds the process burdensome.
So that's why I have chosen GitHub over GitLab. Please realize that this is choosing GitHub to provide repository hosting and code review; we are not moving our issue tracker, nor are we moving our wiki. And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
Thanks to everyone who contributed to this decision, especially Donald, Barry, and Nick for making the proposals we had to work from.
We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :)
This will likely require a new PEP, that should cover: 1) the new workflow (including how to handle reviews -- see below); 2) the steps required for the migration and a timeline; 3) a list of things that will break and/or that will need to be added/replaced before/during/after the migration; 4) the fate of hg.python.org; Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :). Above you said that GitHub will be used for reviews but we will keep using our bug tracker. This leads to the following questions: * Do GitHub reviews only work for pull requests? * Are we still going to support uploading diffs/patches to the tracker (short term and long term)? * If so, how/where are we going to review those diffs/patches? * Will patches be automatically converted to pull requests, or pull requests converted to patches and attached to b.p.o issues? * Are there plans to migrate existing Rietveld reviews to GitHub and shut Rietveld down for good? * If not, will Rietveld stay around and be read-only? Or will it still be used for patches uploaded to b.p.o? * What else is needed to integrate GitHub and b.p.o? About points 3 of the initial list, these are some examples of things that will need to be added/updated/replaced: * the hgroundup hook[2] that post messages to b.p.o when a commit includes an issue number needs to be replaced; * the hgirker hook[3] used for deadparrot on #python-dev needs to be replaced (probably there is already an irker-git hook that can be used/adapted); * the hgbuildbot[4] hook that triggers the buildbots on commit needs to be replaced; * other hg hooks[5] might need to be rewritten/replaced; * the script[6] that generates bug tracker links to hg.p.o needs to be updated (for both cs ids and paths); * the hg code that converts issue links in commit messages to b.p.o links needs to be replaced; * other places where issue numbers appears on GitHub should generate links to b.p.o; * the hg-cpydev hg extension [7] should be ported to git (optional); * the buildbots need to be updated if they are going to pull the source from github and use git; * the bug tracker will need to be updated to interact with github; * the devguide needs to be updated (both to cover the new workflow and update links/commands); FWIW next weekend (9-10 January) we are organizing a sprint in Helsinki, and I'm planning to work on the bug tracker, so I might be able to start addressing some of these points. Best Regards, Ezio Melotti P.S. enjoy your last few days of vacation while you can ;) [0]: https://www.python.org/dev/peps/pep-0507/ [1]: https://www.python.org/dev/peps/pep-0481/ [2]: https://hg.python.org/hooks/file/tip/hgroundup.py [3]: https://hg.python.org/hooks/file/tip/hgirker.py [4]: https://hg.python.org/hooks/file/tip/hgbuildbot.py [5]: https://hg.python.org/hooks/file/tip [6]: https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.p... [7]: https://bitbucket.org/introom/hg-cpydev
I was purposefully trying to avoid having this discussion start until Monday, but since Ezio sort has a deadline for issue-related stuff we can start on that side now (I still have an email planned on Monday to outline the initial steps to moving things over and the very first hurdle to work through). On Fri, 1 Jan 2016 at 17:57 Ezio Melotti <ezio.melotti@gmail.com> wrote:
Hi,
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
No major distinguishing features between GitHub or GitLab Familiarity amongst core devs -- and external contributors -- with GitHub Guido prefers GitHub
Neither platform had some mind-blowing feature(s) that really made them stand out from each other such that it would greatly simplify our lives if we chose one platform over another. I obviously was really hoping there was going to be something I missed, but nothing ever came up (and no, being open source is not enough of a feature; as I said when I started this process, being open source would help break ties or minor lead of one tool but not be a deciding factor).
But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub. I think most of that stemmed from having used GitHub for other open source projects and/or work, making even dormant core devs say they would be able to become active again if we switched to GitHub thanks to eliminating the barrier of having to keep up with our custom workflow for code reviews and using hg for commits. And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub.
And at least for me, the fact Guido prefers GitHub means something. While Guido himself would say I shouldn't really worry about his preferences since he is only an occasional contributor at this point, I believe that it's important that our BDFL actually like contributing to his own programming language rather than potentially alienating him because he finds the
burdensome.
So that's why I have chosen GitHub over GitLab. Please realize that this is choosing GitHub to provide repository hosting and code review; we are not moving our issue tracker, nor are we moving our wiki. And the long-term
On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon <brett@python.org> wrote: process plan
is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
Thanks to everyone who contributed to this decision, especially Donald, Barry, and Nick for making the proposals we had to work from.
We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :)
This will likely require a new PEP, that should cover: 1) the new workflow (including how to handle reviews -- see below); 2) the steps required for the migration and a timeline; 3) a list of things that will break and/or that will need to be added/replaced before/during/after the migration; 4) the fate of hg.python.org;
Yes to all of that.
Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :).
It will be either be a new PEP or the GitHub PEP will simply be rewritten.
Above you said that GitHub will be used for reviews but we will keep using our bug tracker.
Yes, we are not moving to GitHub's issue tracker.
This leads to the following questions: * Do GitHub reviews only work for pull requests?
What do you mean by this? Do you mean by patch upload?
* Are we still going to support uploading diffs/patches to the tracker (short term and long term)?
Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld).
* If so, how/where are we going to review those diffs/patches?
I don't know. Is it possible to have the bot create a PR for an uploaded patch?
* Will patches be automatically converted to pull requests, or pull requests converted to patches and attached to b.p.o issues?
I don't think we need to upload a patch file if we already have a PR, but we should either have a PR -> issue or issue -> PR mapping somehow. This can either be via bot command or specifying a PR # in the issue tracker. I also have no issue if people want to make PRs generate patches for the issue as well for backup purposes, but that might get a bit noisy for those following both an issue and a PR.
* Are there plans to migrate existing Rietveld reviews to GitHub and shut Rietveld down for good?
Yes, there are plans to shut Rietveld down. I suspect we will leave it up until GitHub is running in an equivalent fashion to our current workflow, then we will have a deadline to work through any outstanding reviews and then close it up (and if we want to be thorough, set Rietveld so that it won't work on new issues and only pre-existing ones that already have a patch).
* If not, will Rietveld stay around and be read-only? Or will it still be used for patches uploaded to b.p.o?
We are trying to cut down on the infrastructure we maintain, so I don't want Rietveld sticking around indefinitely.
* What else is needed to integrate GitHub and b.p.o?
Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to make the association. No reason we can't have both, though. But either way we should have a way to connect PRs to issues. If a bot can create PRs from a patch, then that would be nice for folks who don't want to use GitHub, but I don't consider that a priority. I'm happy to try to be accommodating to people who don't want to use GitHub for whatever reason, there is a limit to how much energy we should put into supporting that scenario past uploading a patch.
About points 3 of the initial list, these are some examples of things that will need to be added/updated/replaced: * the hgroundup hook[2] that post messages to b.p.o when a commit includes an issue number needs to be replaced; * the hgirker hook[3] used for deadparrot on #python-dev needs to be replaced (probably there is already an irker-git hook that can be used/adapted); * the hgbuildbot[4] hook that triggers the buildbots on commit needs to be replaced; * other hg hooks[5] might need to be rewritten/replaced; * the script[6] that generates bug tracker links to hg.p.o needs to be updated (for both cs ids and paths); * the hg code that converts issue links in commit messages to b.p.o links needs to be replaced; * other places where issue numbers appears on GitHub should generate links to b.p.o; * the hg-cpydev hg extension [7] should be ported to git (optional); * the buildbots need to be updated if they are going to pull the source from github and use git; * the bug tracker will need to be updated to interact with github; * the devguide needs to be updated (both to cover the new workflow and update links/commands);
Yes to all of these (I think; depends if we change how something operates in terms of associations).
FWIW next weekend (9-10 January) we are organizing a sprint in Helsinki, and I'm planning to work on the bug tracker, so I might be able to start addressing some of these points.
I think deciding how to associate issues with PRs would be a great thing to work through. Otherwise we need to decide if we want to go with an issue tracker solution to the NEWS file or if we want a individual file solution (which happens to be bot-friendly). Those two things are probably the most critical starting points. -Brett
Best Regards, Ezio Melotti
P.S. enjoy your last few days of vacation while you can ;)
[0]: https://www.python.org/dev/peps/pep-0507/ [1]: https://www.python.org/dev/peps/pep-0481/ [2]: https://hg.python.org/hooks/file/tip/hgroundup.py [3]: https://hg.python.org/hooks/file/tip/hgirker.py [4]: https://hg.python.org/hooks/file/tip/hgbuildbot.py [5]: https://hg.python.org/hooks/file/tip [6]: https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.p... [7]: https://bitbucket.org/introom/hg-cpydev
On Sat, Jan 2, 2016 at 8:45 PM, Brett Cannon <brett@python.org> wrote:
I was purposefully trying to avoid having this discussion start until Monday, but since Ezio sort has a deadline for issue-related stuff we can start on that side now (I still have an email planned on Monday to outline the initial steps to moving things over and the very first hurdle to work through).
No hurry, there's still a week before the sprint so take your time. I also still have to merge all the GSoC improvements before looking at these other issues.
On Fri, 1 Jan 2016 at 17:57 Ezio Melotti <ezio.melotti@gmail.com> wrote:
Hi,
On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon <brett@python.org> wrote:
... We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :)
This will likely require a new PEP, that should cover: 1) the new workflow (including how to handle reviews -- see below); 2) the steps required for the migration and a timeline; 3) a list of things that will break and/or that will need to be added/replaced before/during/after the migration; 4) the fate of hg.python.org;
Yes to all of that.
Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :).
It will be either be a new PEP or the GitHub PEP will simply be rewritten.
OK.
Above you said that GitHub will be used for reviews but we will keep using our bug tracker.
Yes, we are not moving to GitHub's issue tracker.
This leads to the following questions: * Do GitHub reviews only work for pull requests?
What do you mean by this? Do you mean by patch upload?
With reviews here I mean inline comments similar to the ones you can add on Rietveld. I haven't used GitHub yet, but I assume this can be done for pull requests (same as with BitBucket) and perhaps for patches attached to the GitHub bug tracker. Since we are not going to use the GitHub bug tracker, only pull requests can be reviewed on GitHub. If someone uploads a patch on the bug tracker it won't be possible to review it unless we convert it to a pull request (or unless we keep Rietveld around, but we don't want that).
* Are we still going to support uploading diffs/patches to the tracker (short term and long term)?
Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld).
Only supporting pull requests will force all contributors to use GitHub (unless GitHub supports "external" pull requests). I think we should keep supporting plain patches as an alternative, and write tools to convert those to pull requests. If GitHub doesn't support "external" pull requests, we might also be able to write additional tools to do so from the tracker directly.
* If so, how/where are we going to review those diffs/patches?
I don't know. Is it possible to have the bot create a PR for an uploaded patch?
It should be possible -- we will need an account for b.p.o and then b.p.o can commit the patches on its clone (perhaps using a different branch for issue/patch) and send a pull request to the main clone (for the last bit we might need to use the GitHub API, unless there are other ways).
* Will patches be automatically converted to pull requests, or pull requests converted to patches and attached to b.p.o issues?
I don't think we need to upload a patch file if we already have a PR,
The goal is to have everything in the same place, even if contributions are made both via pull requests and via patches uploaded to b.p.o. I think the best option is to convert all patches uploaded to b.p.o to pull requests, so that all the reviews happen on GitHub.
but we should either have a PR -> issue or issue -> PR mapping somehow. This can either be via bot command or specifying a PR # in the issue tracker.
b.p.o should automatically link to PRs when "PR num" appears in a message (this can be done easily). GitHub should also link to b.p.o issues when an issue number appears in the PR (I don't know if/how this can be done). For patches uploaded to b.p.o, a link to the generated PR can be added where the "review" link is now.
I also have no issue if people want to make PRs generate patches for the issue as well for backup purposes, but that might get a bit noisy for those following both an issue and a PR.
I'm not sure we need to generate a diff and attach it to the issue, but PRs related to the issue should probably be listed on b.p.o where the list of patches currently is. One possible reason to add patches is the new patch analysis tool written during GSoC that can extract metadata from patches (affected files, whether the patch has tests/docs, etc.) which in turn can be used during searches. The tool can also be adapted to generate the diff dynamically and extract metadata from there though.
* Are there plans to migrate existing Rietveld reviews to GitHub and shut Rietveld down for good?
Yes, there are plans to shut Rietveld down. I suspect we will leave it up until GitHub is running in an equivalent fashion to our current workflow,
Good to know.
then we will have a deadline to work through any outstanding reviews and then close it up (and if we want to be thorough, set Rietveld so that it won't work on new issues and only pre-existing ones that already have a patch).
Or we could just copy-paste the reviews as messages on the tracker so that languishing reviews don't hold up the Rietveld demise.
* If not, will Rietveld stay around and be read-only? Or will it still be used for patches uploaded to b.p.o?
We are trying to cut down on the infrastructure we maintain, so I don't want Rietveld sticking around indefinitely.
Agreed.
* What else is needed to integrate GitHub and b.p.o?
Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to make the association. No reason we can't have both, though. But either way we should have a way to connect PRs to issues.
I'll have to think a bit about the best way to implement this and the UI (I already have some ideas).
If a bot can create PRs from a patch, then that would be nice for folks who don't want to use GitHub, but I don't consider that a priority. I'm happy to try to be accommodating to people who don't want to use GitHub for whatever reason, there is a limit to how much energy we should put into supporting that scenario past uploading a patch.
If we want to support this (and I think we should) we will either need a bot (actually a Roundup detector) or a human to do it, and the former sounds better.
About points 3 of the initial list, these are some examples of things that will need to be added/updated/replaced: * the hgroundup hook[2] that post messages to b.p.o when a commit includes an issue number needs to be replaced; * the hgirker hook[3] used for deadparrot on #python-dev needs to be replaced (probably there is already an irker-git hook that can be used/adapted); * the hgbuildbot[4] hook that triggers the buildbots on commit needs to be replaced; * other hg hooks[5] might need to be rewritten/replaced; * the script[6] that generates bug tracker links to hg.p.o needs to be updated (for both cs ids and paths); * the hg code that converts issue links in commit messages to b.p.o links needs to be replaced; * other places where issue numbers appears on GitHub should generate links to b.p.o; * the hg-cpydev hg extension [7] should be ported to git (optional); * the buildbots need to be updated if they are going to pull the source from github and use git; * the bug tracker will need to be updated to interact with github; * the devguide needs to be updated (both to cover the new workflow and update links/commands);
Yes to all of these (I think; depends if we change how something operates in terms of associations).
FWIW next weekend (9-10 January) we are organizing a sprint in Helsinki, and I'm planning to work on the bug tracker, so I might be able to start addressing some of these points.
I think deciding how to associate issues with PRs would be a great thing to work through. Otherwise we need to decide if we want to go with an issue tracker solution to the NEWS file or if we want a individual file solution (which happens to be bot-friendly). Those two things are probably the most critical starting points.
There's also another point that I haven't seen being discussed: how we will handle the author and the committer fields. Currently we only know the committer so, while migrating to git, this can either be duplicated in the author field or just preserved in the committer field leaving the author field empty. Afterwards we can start using the two fields for what they are meant for. A possible problem is how to update them when commits/merges are performed by bots (e.g. if b.p.o automatically converts a patch into a pull request, or if a core dev merges a patch by clicking on a button). Perhaps someone more familiar with Git/GitHub can clarify this (I think it's possible to specify author/committer manually, but I don't know how GitHub handles it on its side). Best Regards, Ezio Melotti
-Brett
Best Regards, Ezio Melotti
P.S. enjoy your last few days of vacation while you can ;)
[0]: https://www.python.org/dev/peps/pep-0507/ [1]: https://www.python.org/dev/peps/pep-0481/ [2]: https://hg.python.org/hooks/file/tip/hgroundup.py [3]: https://hg.python.org/hooks/file/tip/hgirker.py [4]: https://hg.python.org/hooks/file/tip/hgbuildbot.py [5]: https://hg.python.org/hooks/file/tip [6]: https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.p... [7]: https://bitbucket.org/introom/hg-cpydev
On Jan 2, 2016, at 5:35 PM, Ezio Melotti <ezio.melotti@gmail.com> wrote:
GitHub should also link to b.p.o issues when an issue number appears in the PR (I don't know if/how this can be done).
By default this isn’t allowed, but I think you could use the web hook based support in Github with a bot that has permissions to just inline edit comments so that the typical syntax gets linked to b.p.o. This won’t work in commit messages or such though. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sun, Jan 3, 2016 at 12:35 AM, Ezio Melotti <ezio.melotti@gmail.com> wrote:
On Sat, Jan 2, 2016 at 8:45 PM, Brett Cannon <brett@python.org> wrote:
Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to make the association. No reason we can't have both, though. But either way we should have a way to connect PRs to issues.
I'll have to think a bit about the best way to implement this and the UI (I already have some ideas).
This can be done without a bot. We just need a webhook server to listen pull_request[1] events. If the action type of the event is "opened" and the pull request title contains "Issue #NNNN", we can communicate with the new Roundup detector. I don't know how the Roundup part works, though. [1] https://developer.github.com/v3/activity/events/types/#pullrequestevent
There's also another point that I haven't seen being discussed: how we will handle the author and the committer fields. Currently we only know the committer so, while migrating to git, this can either be duplicated in the author field or just preserved in the committer field leaving the author field empty. Afterwards we can start using the two fields for what they are meant for. A possible problem is how to update them when commits/merges are performed by bots (e.g. if b.p.o automatically converts a patch into a pull request, or if a core dev merges a patch by clicking on a button). Perhaps someone more familiar with Git/GitHub can clarify this (I think it's possible to specify author/committer manually, but I don't know how GitHub handles it on its side).
There is no way to store both contributor and committer information via GitHub's web interface. It can be done either manually in terminal or a bot can temporarily set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL env variables before doing fast-forward merge (we can get the core developer's name and email address from https://developer.github.com/v3/issues/comments/ and https://developer.github.com/v3/users/)
On Jan 02, 2016, at 06:45 PM, Brett Cannon wrote:
Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :).
It will be either be a new PEP or the GitHub PEP will simply be rewritten.
Please either write a new PEP, or just write some draft new chapters for the developer's guide. Ultimately, anything that a developer has to care about really needs to be described in the devguide. Cheers, -Barry
On 3 January 2016 at 13:50, Barry Warsaw <barry@python.org> wrote:
On Jan 02, 2016, at 06:45 PM, Brett Cannon wrote:
Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :).
It will be either be a new PEP or the GitHub PEP will simply be rewritten.
Please either write a new PEP, or just write some draft new chapters for the developer's guide. Ultimately, anything that a developer has to care about really needs to be described in the devguide.
For the last hosting transition, PEP 374 covered the process of choosing a distributed VCS, while PEP 385 covered the actual Subversion -> Mercurial transition, and I think that's a good way to go. In particular, a separate "Migrating from hg.python.org to GitHub" PEP provides a place to document the TODO list for the transition, and the outcomes of any smaller decisions that will need to be made as an incidental part of the migration (like handling Author/Committer data for old commits), which aren't generally relevant to future contributors (so don't belong in the developer guide), but also weren't part of the repository hosting decision making process (so don't really belong in PEP 507). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I'm planning to write a separate PEP. I'll start outlining what I think we need to accomplish and in what order on Monday and that will be the kick-off for the outline of the PEP so we can get a good feel for the work to be done (roughly). On Sat, 2 Jan 2016, 21:40 Nick Coghlan <ncoghlan@gmail.com> wrote:
On Jan 02, 2016, at 06:45 PM, Brett Cannon wrote:
Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :).
It will be either be a new PEP or the GitHub PEP will simply be rewritten.
Please either write a new PEP, or just write some draft new chapters for
On 3 January 2016 at 13:50, Barry Warsaw <barry@python.org> wrote: the
developer's guide. Ultimately, anything that a developer has to care about really needs to be described in the devguide.
For the last hosting transition, PEP 374 covered the process of choosing a distributed VCS, while PEP 385 covered the actual Subversion -> Mercurial transition, and I think that's a good way to go.
In particular, a separate "Migrating from hg.python.org to GitHub" PEP provides a place to document the TODO list for the transition, and the outcomes of any smaller decisions that will need to be made as an incidental part of the migration (like handling Author/Committer data for old commits), which aren't generally relevant to future contributors (so don't belong in the developer guide), but also weren't part of the repository hosting decision making process (so don't really belong in PEP 507).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On Jan 03, 2016, at 03:40 PM, Nick Coghlan wrote:
For the last hosting transition, PEP 374 covered the process of choosing a distributed VCS, while PEP 385 covered the actual Subversion -> Mercurial transition, and I think that's a good way to go.
Yes, for the transition tasks, a PEP makes sense. This is essentially a one-off document, at least for the next 5 or 6 years <wink>. But I don't think a PEP is the right place to describe the things that the average developer (core or otherwise) needs to know on a daily basis. That goes in the devguide. Cheers, -Barry
First, let me add my thanks for sorting this out! On Jan 2, 2016 11:45, "Brett Cannon" <brett@python.org> wrote:
Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld).
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c. -eric -eric (phone)
On Sat, 2 Jan 2016 at 20:39 Eric Snow <ericsnowcurrently@gmail.com> wrote:
First, let me add my thanks for sorting this out!
On Jan 2, 2016 11:45, "Brett Cannon" <brett@python.org> wrote:
Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld).
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c.
No one proposed that workflow so it wasn't considered (and I'm obviously not about to start the process again ;). If we find that GitHub isn't working out for code review then we can discuss how to remedy it, but that's not something to consider until we have been done with the transition for several months at least for people to form an informed opinion.
On 4 January 2016 at 03:35, Brett Cannon <brett@python.org> wrote:
On Sat, 2 Jan 2016 at 20:39 Eric Snow <ericsnowcurrently@gmail.com> wrote:
First, let me add my thanks for sorting this out!
On Jan 2, 2016 11:45, "Brett Cannon" <brett@python.org> wrote:
Well, "support" as in "allow". We won't be keeping Rietveld around (part of this move is so we can get off of Rietveld).
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c.
No one proposed that workflow so it wasn't considered (and I'm obviously not about to start the process again ;). If we find that GitHub isn't working out for code review then we can discuss how to remedy it, but that's not something to consider until we have been done with the transition for several months at least for people to form an informed opinion.
The useful aspect of the GitHub-as-platform business model in this case is that while PRs are the *default* review workflow, GitHub's APIs are deliberately designed to let people slot in their own review tools. pip's repo shows what the PR interface looks like with Reviewable enabled, for instance: https://github.com/pypa/pip/pull/3338 (there's just an extra button to jump to the review in the external review tool) For the OpenStack workflow fans, there's http://gerrithub.io/ I can't find any examples of direct integration of Rietveld with GitHub, so that would presumably require setting up some webhooks, similar to what Eric described doing for Reviewboard. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Eric Snow <ericsnowcurrently@...> writes:
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c.
Agreed. Our current Rietveld setup is superior and much less distracting. Like the Rietveld house vs. Victorian architecture. Stefan Krah
Rietveld is no longer an option as our fork of the project is unmaintained (it was one of the key reasons we even started this process). On Sun, Jan 3, 2016, 10:28 Stefan Krah <skrah.temporarily@gmail.com> wrote:
Eric Snow <ericsnowcurrently@...> writes:
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c.
Agreed. Our current Rietveld setup is superior and much less distracting.
Like the Rietveld house vs. Victorian architecture.
Stefan Krah _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
(Though honestly if we were okay with hosting by Google, Rietveld would still be an option. But I agree we should first figure out whether we can live with GitHub's review.) On Sun, Jan 3, 2016 at 11:26 AM, Brett Cannon <brett@python.org> wrote:
Rietveld is no longer an option as our fork of the project is unmaintained (it was one of the key reasons we even started this process).
On Sun, Jan 3, 2016, 10:28 Stefan Krah <skrah.temporarily@gmail.com> wrote:
Eric Snow <ericsnowcurrently@...> writes:
I guess I'd missed this point. In my opinion, code review in Github is unpleasant for anything but small PRs and even for those when there's much back-and-forth. At work we switched to Github. We moved code review off to reviewboard a few months later. Setting up the webhooks between the two wasn't hard and code review was a much better experience. Just my 2c.
Agreed. Our current Rietveld setup is superior and much less distracting.
Like the Rietveld house vs. Victorian architecture.
Stefan Krah _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
-- --Guido van Rossum (python.org/~guido)
Dear Cores-Devs,
[...] And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
please let us known wen/were that bot/automation is going to take place. I've interest on that and I would like to participate :-). Thanks in advance and have a prosperous new year! francis
On Sat, 2 Jan 2016 at 07:01 francismb <francismb@email.de> wrote:
Dear Cores-Devs,
[...] And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
please let us known wen/were that bot/automation is going to take place. I've interest on that and I would like to participate :-).
Thanks for the offer to help! All of that will be discussed on this mailing list, so just stay subscribed and watch out for any details. -Brett
Thanks in advance and have a prosperous new year! francis _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Thank you Brett, Donald, Barry, Nick, Ezio, and all who have worked on core workflow. I believe that moving code review to GitHub will benefit CPython and allow more automated checks and feedback (such as those provided by Travis, codecov, coverage, etc) that will help new contributors as well as save core developers' time. Ezio, Great post on details to think about. Please keep me looped in on issue tracker enhancements (which I know we are not moving) that may make the issue tracker more convenient and appealing to users (similar to PyPi migration to Warehouse). Brett, Enjoy the rest of your well earned vacation. All, Happy New Year and all the best for 2016. Warmly, Carol
Brett Cannon <mailto:brett@python.org> January 1, 2016 at 11:21 AM I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
1. No major distinguishing features between GitHub or GitLab 2. Familiarity amongst core devs -- and external contributors -- with GitHub 3. Guido prefers GitHub
Neither platform had some mind-blowing feature(s) that really made them stand out from each other such that it would greatly simplify our lives if we chose one platform over another. I obviously was really hoping there was going to be something I missed, but nothing ever came up (and no, being open source is not enough of a feature; as I said when I started this process, being open source would help break ties or minor lead of one tool but not be a deciding factor).
But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub. I think most of that stemmed from having used GitHub for other open source projects and/or work, making even dormant core devs say they would be able to become active again if we switched to GitHub thanks to eliminating the barrier of having to keep up with our custom workflow for code reviews and using hg for commits. And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub.
And at least for me, the fact Guido prefers GitHub means something. While Guido himself would say I shouldn't really worry about his preferences since he is only an occasional contributor at this point, I believe that it's important that our BDFL actually like contributing to his own programming language rather than potentially alienating him because he finds the process burdensome.
So that's why I have chosen GitHub over GitLab. Please realize that this is choosing GitHub to provide repository hosting and code review; we are not moving our issue tracker, nor are we moving our wiki. And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
Thanks to everyone who contributed to this decision, especially Donald, Barry, and Nick for making the proposals we had to work from.
We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :) _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
-- Sent from Postbox <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
I'm personally disappointed of course, and not at all surprised, especially after Guido's stated preference. But I want to be very clear that I accept the decision and want to express my thanks also to Brett, Nick, Donald, Guido, and everyone else who contributed to the conversation. It heartening to know that we all care enough about Python, past, present, and future to want to see it succeed not just technically, but socially as well, and decisions about where and how our code will be developed are at least as much social as they are technical. It's also gratifying to know that a subject that can invoke such passion can for the most part be discussed rationally and civilly within our wonderful community. Cheers, -Barry
On Sat, Jan 2, 2016 at 10:41 PM Barry Warsaw barry@python.org <http://mailto:barry@python.org> wrote: It heartening to know that we all care enough about Python, past, present, and future to want to see it succeed not just technically, but socially as well, and decisions about where and how our code will be developed are at least as much social as they are technical. It’s also gratifying to know that a subject that can invoke such passion can for the most part be discussed rationally and civilly within our wonderful community. I’d like to echo this sentiment as well. I’ll also add that Python now joins an impressive list of programming languages hosted and developed on GitHub <https://github.com/showcases/programming-languages>. Some of those languages just use GitHub’s issue tracker (e.g. Go <https://github.com/golang/go>), others just use GitHub pull requests (e.g. Swift <https://github.com/apple/swift/pulls>, Ruby <https://github.com/ruby/ruby>), and others use the full feature set (e.g. Rust <https://github.com/rust-lang/rust>). I hope this transition both enables more people to get involved with Python and lessens the contribution burden on committers. Cheers! Nick
participants (13)
-
Barry Warsaw -
Berker Peksağ -
Brett Cannon -
Carol Willing -
Donald Stufft -
Eric Snow -
Ezio Melotti -
francismb -
Guido van Rossum -
Nicholas Chammas -
Nick Coghlan -
R. David Murray -
Stefan Krah