Should we close issues for platforms not covered by PEP 11 or under active development?

Now that we have an understanding of what platforms we support, should we close out issues for platforms that either we don’t support or no one is actively working towards supporting (e.g. WASM)?

4 Likes

@vstinner suggested to create a label (per OS?) in #48036 (comment). There was also a brief discussion on Discord about the merits of a single label (@zware suggested “OS-Unsupported”) versus a creating a meta-issue before closing versus just doing nothing special and just closing (I believe this was @iritkatriel’s opinion).

I would probably support a label, but there are already a lot of labels on the CPython repo and adding a label explicitly for things we don’t support seems it would just add to the clutter.

A

2 Likes

I agree with closing the issues. They aren’t deleted, just not open. If the platform regains supportable relevance in the future, I expect some would be reopened.

A single “unsupported platform” label of some name someone not-me decides would be fine if anyone wants it, but I agree about label pollution in GitHub’s UX so lets not create per-each-unsupported-thing labelS.

5 Likes

We can also create a (beta) project instead. This has the following advantages:

  • It doesn’t add an extra label;
  • We can add a custom field to group the issues by platform, making it easier to find/filter issues;
  • We can create a custom field to distinguish issues that were already closed (as fixed/invalid) from valid issues that have been closed just because the platform is unsupported (this is not necessary if only issues that are currently open get added).

This was also suggested by @merwok on the issue linked by @AA-Turner, and @vstinner brought up the maintenance burden, however after the initial cost of creating the project, the maintenance is minimal: it’s just a matter of adding the issue to the project before closing it, and possibly setting the right platform field.

3 Likes

Disadvantage of projects:

  • Triagers can’t add/remove issues
5 Likes

Should we close issues for platforms not covered by PEP 11 or under active development?

I don’t think that we have to close these issues. If someone proposes a fix for HP-UX, I just merge it even if I cannot test it. I trust the author of willing to enhance HP-UX support. I just check the change.

There are issues open for less one year, so there is some activity. There are issues open for longer than 5 years: it’s less likely that they are going to be fixed soon. I’m fine that people collaborate on the Python bug tracker to exchange patches via the bug tracker.

The problem is that most of these issues are never fixed and gives more work to bug triagers.

I don’t see the value of a OS-unsupported for someone willing to support an unsupported platform. For example, if there are 100 labels with this label, maybe the platform only has 5 issues in this list. The label doesn’t help much to speed up the search. Plain text keyword search is likely faster in this case.

For me, a project is more “visible” than a label. If you don’t want to add a label, don’t add it it :slight_smile: Some platforms have many issues open, like MinGW. There are people who care.

To be clear, I’m not against closing these issues. Also, I don’t think that we have to create a new label or a new project :wink:

2 Likes

9 posts were split to a new topic: Usability of GitHub projects for triagers

A Beta project is for these issues is now at: Unsupported platforms · GitHub
It works, though like all Beta projects, it’s not as usable for triagers as it could be (see the dedicated thread on that).

If we use that and start closing issues, it would be nice to always link to the project and say that while core devs probably won’t work on the issue, PRs can still be accepted.

3 Likes

I’d like to make “community-supported platforms” a bit more official. Let’s continue the discussion in Community support for a platform, unless you think this should be solved separately.

My proposal there is to add an OS-unsupported label that would auto-add issues to the project. That way, triagers don’t need to care about GitHub projects, or about what happens to the issues later.

1 Like