On Sun, May 20, 2018 at 10:56:21AM +0200, Antoine Pitrou wrote:

If that's on the table, it seems to me that categorization, sorting and filtering on GitHub issues is rather poor, while the basic UI experience (editing messages, etc.) is better. Also, I think customization (e.g. of the default view) is basically inexistent.

Also search via Google "site:bugs.python.org <term>" usually gives quite nice results, while the same for GitHub issues usually does not work at all (far too many unrelated results).

Then there's the original promise of the GitHub migration that in the case of GH bankruptcy or a sudden lockdown the tracker would still be available.

Stefan Krah

On May 20, 2018, at 10:19, Nathaniel Smith <njs@pobox.com> wrote:

IIRC, the general reaction was that it was definitely worth exploring, but that it would be a lot of work and require solutions to a lot of problems to make sure people's workflows weren't too impacted, so we'd need a much more detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager there, was at the packaging mini-summit. If/when we have a specific set of asks for the migration, we can reach out to him and see how they can help. For example, I specifically asked about my favorite GitLab feature “commit when CI passes” and it sounded like they were working on that.

-Barry

On 21 May 2018 at 05:03, Brett Cannon <brett@python.org> wrote:

On Sun, 20 May 2018 at 10:43 Barry Warsaw <barry@python.org> wrote:

...

On May 20, 2018, at 10:19, Nathaniel Smith <njs@pobox.com> wrote:

...

IIRC, the general reaction was that it was definitely worth exploring,

but that it would be a lot of work and require solutions to a lot of problems to make sure people's workflows weren't too impacted, so we'd need a much more detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager there, was at the packaging mini-summit. If/when we have a specific set of asks for the migration, we can reach out to him and see how they can help. For example, I specifically asked about my favorite GitLab feature “commit when CI passes” and it sounded like they were working on that.

There was also general consensus that the state of maintenance for bpo is subpar due to lack of staffing and that more people will need to come forward to help maintain it if we decide to not transition to another issue tracker like GitHub or GitLab.

Right, one of the outcomes of the discussion at the Summit was that any proposal to migrate to a different issue tracker would need to present a clear statement of the *problems intended to be solved*, such that the folks that would prefer to see us stay on our own issue tracker could present a competing proposal to solve those problems without a wholesale migration to another system.

Some examples of problems that would benefit from attention:

• fixing the SSL/TLS connectivity issues
• making the issue tracker usable on mobile devices
• ability to edit the description for issues that evolve over time, not just the title
• improved editing support for comments (both in initial formatting, and in being able to correct errors)
• REST API access to tracker data
• simplifying account creation (especially for folks that already have GitHub accounts)
• rationalising the metadata fields by asking which ones actually see significant use

Some examples of problems that in-place enhancement of the tracker would inherently avoid, but a migration proposal would need to address:

• preservation of existing incoming links to issues
• figuring out which issues to migrate automatically (all of them? None of them? Open issues only?)
• figuring out a new way to track PSF CLA signatures
• figuring out a replacement for the Experts Index integration into the Roundup nosy list
• figuring out replacements for the custom metadata fields that we actually use regularly
• meeting our original GitHub migration commitment to continue offering a way of engaging with the core development process without requiring accounts with any entity other than the PSF

It's far from being a foregone conclusion that migrating to a new issue tracker will be the preferred answer, but there are also genuine problems with the status quo that need to be addressed somehow.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 05/20/2018 10:19 AM, Nathaniel Smith wrote:

On Sun, May 20, 2018, 03:18 Antoine Pitrou <antoine@python.org <mailto:antoine@python.org>> wrote:

Le 19/05/2018 à 02:10, Victor Stinner a écrit :
> Hi,
>
> I failed to get the microphone after Mariatta's secret talk about
> moving Python issues from bugs.python.org
<http://bugs.python.org> (Roundup) to GitHub.

A "secret talk"? What is that?

She gave a talk at the language summit to discuss what people thought of the idea, and she had some fun making the topic a surprise so she could see people's reactions. I don't think there's any secret beyond that.

You have it exactly.  She wanted us (the Language Summit organizers) to keep the talk title a secret until she could reveal it herself in front of the audience.  I suggested the official title on the schedule be "Mariatta's Topic Of Mystery" and we collectively went with that.  At this point nothing about it is a secret.

//arry/

Hi Mariatta,

Le 02/06/2018 à 01:07, Mariatta Wijaya a écrit :

For those who missed it, some resources:

1. My language summit slides (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-prese...) There are 3 bonus slides at the end which I did not get to cover, because we were running late and it was lunchtime. (in the end, we were 3 hrs overtime.) Those can be discussed in core-workflow.

2. LWN article: https://lwn.net/Articles/754779/  I will not be reading/responding to the comments in LWN. 🤐

Thanks for the pointers.

I agree with the UI concerns about b.p.o. But I also agree with the response mentioned in LWN. Especially the lack of categorization in Github issues.

I've used Github issues on other projects. It's fine when you have a small-to-medium number of open issues (say, no more than a couple hundreds). But I don't think it's usable for a project with several thousands issues open. At a micro level, the editing UI is pleasant to use. But at a more macro level, it's rather painful to navigate in a large number of issues.

I wonder if other hosted services, such as Gitlab, offer a more sophisticated issue tracker.

Regards

Antoine.

On 1 June 2018 at 20:29, Barry Warsaw <barry@python.org> wrote:

On Jun 1, 2018, at 16:54, Antoine Pitrou <antoine@python.org> wrote:

...

I wonder if other hosted services, such as Gitlab, offer a more sophisticated issue tracker.

Note that GitHub (and I think GitLab too) provides two additional ways to categorise issues: project boards, and milestones. I think together with labels this may simulate current b.p.o. structure to certain extent. For example (approximately): triaged, PR review

• We can have milestones for releases (including past releases)
• We can have "project boards" (slightly abusing this feature): new,

• Labels can be grouped using name prefix and color, for example (we have similar structure in mypy):
  • priority-low
  • priority-normal
  • priority-etc...
  • kind-bug
  • kind-docs
  • kind-feature
  • topic-asincio
  • topic-etc..

This is still quite limited, but together with bots this can practically replace current categorisation.

-- Ivan

On 6/1/2018 7:07 PM, Mariatta Wijaya wrote:

Yup, the "mystery" was just for fun 😛 There is no secret. I've been thinking that we should start using GitHub issues instead of the b.p.o.

I realized not everyone was able to get to the language summit, and I fully intended to update python-committers with this idea. I just haven't been reading the mailing list for sometime until today.

For those who missed it, some resources:

1. My language summit slides (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-prese...)

"Old and languishing issues should just be closed / ignored"

I disagree with doing this blindly, and I would be mightily annoyed if someone did so with IDLE issues and hide valuable ideas and code. For example:

In Sept 2006, Tal Einat suggested that IDLE's class browser, based on the pyclbr module, should report nested classed. https://bugs.python.org/issue1612262

In August 2009, Guilherme Polo submitted patches for pyclbr and IDLE that also supported nested functions. https://bugs.python.org/issue6691 I discovered the issue and approved of the idea in Sept 2015

In June and July 2017, Cheryl Sabella and I updated, rewrote, finished, and merged both patches.

To deal with issues better, we need

1. More core developers, so more modules can have maintainers.

2. Better support for core developers in the tracker.

2a. The ability to tag issues with the module (or perhaps modules) that an issue more pertains to.

2b. Associated (linked) manager or dashboard for issues pertaining to a module or group of modules.

There are currently about 60 idlelib module and 250 IDLE issues. To not go crazy or become paralyzed, I keep a list (in a file) organized by topics, which mostly correspond to modules. Since I started this, I have closed perhaps 40-50 issues. For one thing, collecting together issues pertaining to a topic/module makes it easy to spot out of date and duplicate issues.

If I could tag IDLE issues with module names and retrieve them by module, that would partly duplicate what I have done. It would also be nice to have the line online, and public, with issue numbers linking back to issues. It would be nice if tagging an issue caused it to be automatically added to the appropriate sublist.

Would moving to github make such a substantial improvement?

There are 3 bonus slides at the end which I did not get to cover, because we were running late and it was lunchtime. (in the end, we were 3 hrs overtime.)

Automerge: should signal separate from 'I approve of this PR'. Commit message can be put in a labelled comment. I have started editing the initial commit message.

tjr