PEP 581: Using GitHub Issues for CPython
I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython Full text: https://www.python.org/dev/peps/pep-0581/ This is my first PEP, and in my opinion it is ready for wider discussion. I don't know if it is "ready for pronouncement" so I'm hoping to get more guidance about it from other experienced core devs and steering council. I also plan to open discussion about PEP 581 at Python Language Summit, and since I'm one-half of the language summit chairs, it is quite likely this discussion will happen. On that note, you can still sign up for the language summit here: https://us.pycon.org/2019/events/language-summit/ Note that unlike previous years, you do not need to be invited by a core developer. Łukasz and I will be curating the content, and we want to include more diverse perspectives into language summit discussions. Thanks. ᐧ
I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython
Full text: https://www.python.org/dev/peps/pep-0581/
Thanks for doing this. I think there is a pretty strong argument to be made that mature, widely adopted systems like GitHub (or GitLab or Bitbucket) should be used where possible. One thing I didn't notice was any sort of explanation about how CPython wound up on Roundup to begin with. I think it would be worthwhile to mention a couple reasons, when the decision was made to use Roundup, etc. Without it, a casual reader might think the core devs made a horrible mistake way back when, and are only now getting around to correcting it. I don't recall when Roundup was adopted, but it was quite awhile ago, and the issue tracker universe was a much different place. Here are a couple things I recall (perhaps incorrectly). It's been awhile, but for the digital spelunkers, I'm sure it's all in an email archive somewhere. (I didn't find a PEP. Did that decision predate PEPs?) * Back in the olden days, basically every candidate issue tracker required modification to make it suitable for a particular project. I don't rightly recall if Roundup was deemed easier to modify or if there were just people willing to step up and make the necessary changes. * There was a desire to eat your own dog food, and I believe Roundup is/was written in Python. That would be much less important today. Plenty of people already eat Python brand Dog Food.™ Skip
On Thu, Mar 7, 2019 at 2:02 PM Skip Montanaro <skip.montanaro@gmail.com> wrote:
I think it would be worthwhile to mention a couple reasons, when the decision was made to use Roundup, etc. Without it, a casual reader might think the core devs made a horrible mistake way back when, and are only now getting around to correcting it.
I was not involved in core Python development back then, so if it is really important and if people think such paragraph needs to be part of the PEP, then perhaps someone else more knowledgeable will need to help with this. Personally, I don't think it was a horrible mistake. I believe the core devs back then carefully considered all options and decided that bpo/roundup was the way to go. And I really don't want to give that impression to the readers of this PEP that "I" or "core devs" now think it was a horrible mistake. If there is specific parts of the PEP that gives people that impression, then I'd definitely want to work and improve that. ᐧ
On Mar 7, 2019, at 14:36, Mariatta <mariatta@python.org> wrote:
I was not involved in core Python development back then, so if it is really important and if people think such paragraph needs to be part of the PEP, then perhaps someone else more knowledgeable will need to help with this.
Personally, I don't think it was a horrible mistake. I believe the core devs back then carefully considered all options and decided that bpo/roundup was the way to go. And I really don't want to give that impression to the readers of this PEP that "I" or "core devs" now think it was a horrible mistake. If there is specific parts of the PEP that gives people that impression, then I'd definitely want to work and improve that.
I did a little bit of archive archeology (always a frightening and humbling black hole spelunking expedition), and here’s a brief history AFAICT. Dates are approximate. 5/2000 - we move all development (CVS at the time, and bug tracking) to SourceForge. This roughly coincided with PythonLabs leaving CNRI, so clearly we couldn’t continue running infra off of their systems. 10/2005 - we move to Subversion 9/2006 - we begin to discuss moving off of the SF bug tracker. I believe that Thomas Wouters, Martin von Loewis, Brett Cannon (big surprise! :), and myself were involved in that effort, with Richard Jones (original author of Roundup) recusing himself. The candidates were Roundup, Trac, Jira, and Launchpad. I think Brett did the first round of feature reviews and comparisons. David Goodger was also involved. We did want it to be written in Python and we preferred running it on python.org infra, but neither of these were required criteria. Jira and Roundup made the first cuts, with Launchpad and Trac being discarded as “having issues” (I don’t have access in memory or emails to any of those details). Jira was deemed pretty complex, but Atlassian offered hosting. Roundup was “not as polished" back then, but that wasn’t necessarily a negative. It was easy to use and host, and had a complimentary feature set, but we felt like we needed volunteers to help us keep it going. Richard Jones of course did fantastic work on the software itself, and we did manage to, um, round up enough volunteers to make it a viable choice. 10/2006 - the decision was made to move to Roundup, and we decided to accept Upfront’s offer to host the instance. 3/2007 - new-bugs-announce was created and notifications of new bugs was redirected to that mailing list. I’ll disappear down that archive rabbit hole now, which in some cases goes back to 1995. There are so many fun and scary paths to explore. See you in 6 months. jeremy-is-salty-ly y’rs, -Barry
I'll start by saying I don't think a history lesson is important for this PEP. This is simply a matter of evaluating whether Roundup or GitHub issues is better for us and in the future. There's no real mistakes to watch out for or anything (and if there is it's that self-hosting has a cost ;) . On Thu, Mar 7, 2019 at 3:38 PM Barry Warsaw <barry@python.org> wrote:
On Mar 7, 2019, at 14:36, Mariatta <mariatta@python.org> wrote:
I was not involved in core Python development back then, so if it is really important and if people think such paragraph needs to be part of the PEP, then perhaps someone else more knowledgeable will need to help with this.
Personally, I don't think it was a horrible mistake. I believe the core devs back then carefully considered all options and decided that bpo/roundup was the way to go. And I really don't want to give that impression to the readers of this PEP that "I" or "core devs" now think it was a horrible mistake. If there is specific parts of the PEP that gives people that impression, then I'd definitely want to work and improve that.
I did a little bit of archive archeology (always a frightening and humbling black hole spelunking expedition), and here’s a brief history AFAICT. Dates are approximate.
5/2000 - we move all development (CVS at the time, and bug tracking) to SourceForge. This roughly coincided with PythonLabs leaving CNRI, so clearly we couldn’t continue running infra off of their systems.
10/2005 - we move to Subversion
9/2006 - we begin to discuss moving off of the SF bug tracker. I believe that Thomas Wouters, Martin von Loewis, Brett Cannon (big surprise! :), and myself were involved in that effort, with Richard Jones (original author of Roundup) recusing himself. The candidates were Roundup, Trac, Jira, and Launchpad. I think Brett did the first round of feature reviews and comparisons. David Goodger was also involved. We did want it to be written in Python and we preferred running it on python.org infra, but neither of these were required criteria.
This was actually my first infrastructure project and how I ended up on the PSF board and the head of the infrastructure group. :)
Jira and Roundup made the first cuts, with Launchpad and Trac being discarded as “having issues” (I don’t have access in memory or emails to any of those details). Jira was deemed pretty complex, but Atlassian offered hosting. Roundup was “not as polished" back then, but that wasn’t necessarily a negative. It was easy to use and host, and had a complimentary feature set, but we felt like we needed volunteers to help us keep it going. Richard Jones of course did fantastic work on the software itself, and we did manage to, um, round up enough volunteers to make it a viable choice.
10/2006 - the decision was made to move to Roundup, and we decided to accept Upfront’s offer to host the instance.
You're missing the step of "the decision was made to move to Jira and people flipped out." :) We actually said Jira was our choice unless enough people came forward to volunteer to help support us using Roundup. In the end enough people did step forward and people didn't like us using Java and a closed-source solution, so we went with Roundup (this is when RMS got involved and asked us to reconsider; this is also when I learned that volunteers saying they will help with something doesn't mean they actually will, especially when they have no established reputation ;) . The original announcement can be found at https://mail.python.org/pipermail/python-dev/2006-October/069139.html. -Brett
3/2007 - new-bugs-announce was created and notifications of new bugs was redirected to that mailing list.
I’ll disappear down that archive rabbit hole now, which in some cases goes back to 1995. There are so many fun and scary paths to explore. See you in 6 months.
jeremy-is-salty-ly y’rs, -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/brett%40python.org
On Fri, Mar 8, 2019 at 12:41 AM Mariatta <mariatta@python.org> wrote:
I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython
Full text: https://www.python.org/dev/peps/pep-0581/
Thanks a lot for doing this! * The current bug tracker has low contributions and moving to a place like GitHub would open up to a lot of opportunities like integrations, webhooks where people can build custom workflow etc. along with reducing the maintenance burden on the team. * GitHub also allows markdown and syntax highlighting on code snippets would be much easier to read compared to current tracker. In some cases GitHub can even inline the code for a permalink to a single line which adds more context. Also support for editing comments to fix minor typos links are great. Emoji support :) * The current bpo search is surprisingly very effective though it just does substring search across comments and patches I believe. If not I can google keywords with site:bugs.python.org to get relevant results. I expect search to be better on GitHub but worth experimenting since searching to get related issues/discussion helps a lot in triaging. Some points worth considering and some of them are addressed in the PEP already. * Moving to GitHub also comes at a cost of accessibility where there might be people posting questions that are more suitable for stackoverflow, python-list etc. Thus there might be more incoming issues that would require more effort on triaging. * There could be explicit guidelines on when a triager should close an issue and current bpo supports custom fields for resolution, state of the issue (open/close/pending/needs-test/patch-review) that are updated. Besides closing the issue there could be labels or a comment format to describe the rationale and resolution. * There could also be guidelines on when to lock the thread since there could be cases where security issues or issues that can trigger heated arguments are posted. It could get even more attention when it's posted on Reddit or hackernews attracting unwanted attention e.g. security issues in npm posted to reddit. Someone can chime in to lock it but guidelines on when to do this would be helpful so that decision is not based on personal opinion to lock it. * Extended discussions in some cases along with no proper support for threading could result in lot of duplicated messages that would be hard to scroll through. It's a problem with current tracker too but something that can come up where people will use +1 comments instead of using thumbs up emoji. Rust community had some similar concerns since they do RFC discussions on GitHub that result in 200+ comments. Though we don't do PEP discussions some bugs can result in this. * I wish python-bug-list, weekly summary continues to be integrated with GitHub too since some of us don't want to watch the repo to get all the activity along with pull requests and just want to track activity on issues. * Currently there is some link rot on bpo for svn related links, broken patch file links etc. Moving to GitHub I guess they are handled like magic links for PEPs, bpo-NNNN, etc. that are mentioned in the PEP 581. Personally, I think more people will love it once they get to use it so if something like 100 issues can be migrated to a sample repo with labels, content etc. As a shameless plug I tried migrating around 150 issues in current bpo to GitLab sometime back with components as labels. Though an apple to oranges comparison (GitLab UI vs GitHub UI) I personally find the UI (also GitHub UI) very easy to navigate in terms of clicking on labels, search, sort, filter etc. in https://gitlab.com/tirkarthi/python-bugs/issues and the issue is more easy to read with markdown support for code where I added highlight to snippet https://gitlab.com/tirkarthi/python-bugs/issues/140 -- Regards, Karthikeyan S
On Fri, 8 Mar 2019 at 16:52, Karthikeyan <tir.karthi@gmail.com> wrote:
Personally, I think more people will love it once they get to use it so if something like 100 issues can be migrated to a sample repo with labels, content etc.
We're already using GitHub issues for pretty much everything in Python core development that *isn't* CPython itself, and even for CPython, folks experience the core issue management interface in the overview page for pull requests. One of the requests we made at the Language Summit discussion last year was for Mariatta to enhance PEP 581 with additional discussion of what would need to change to bring the Roundup instance up to the point of being competitive with the GitHub issues user experience, which she added: * https://www.python.org/dev/peps/pep-0581/#issues-with-roundup-bpo * https://www.python.org/dev/peps/pep-0581/#why-not-focus-on-improving-roundup... There's been plenty of time since then for folks to put forward a competing proposal to modernise the Roundup UI directly instead of migrating to a different issue tracking tool, but so far no such proposal has emerged. One of the other blockers was the fact that the Contributor Licensing Agreement process was tightly coupled to some custom fields in b.p.o [1], and that is now very close to being resolved thanks to Mariatta's efforts (and provides a nice workflow improvement in its own right). Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0581/#update-the-cla-host -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Barry Warsaw -
Brett Cannon -
Karthikeyan -
Mariatta -
Nick Coghlan -
Skip Montanaro