The users can’t set labels anyway, so if they report it, they would have to do it in the message (an issue template might help here). Even if they do, they generally just report the version they are using, and while useful, it doesn’t tell us if other versions are affected (and if you only see e.g. 3.9, does it mean that 3.9 is the only affected version, or the only version tested?).
As new releases come out, the version labels need to be updated, new versions added and old versions removed (both on the label list and on all the issues). Given this dynamic nature, it’s difficult to trust the labels (does this issue list only 3.9 and 3.10 because 3.11 is not affected or because no one added the 3.11 label when 3.11 came out?).
IME triagers just update the issue with all maintained versions, with a few exceptions (the issue is related to a newly-introduced feature, or the issue has been fixed already). This is generally a fair assumption, but it’s not supported by evidence unless the triagers try to reproduce the issue on different versions (and we can’t expect every triager to do that).
IOW, version labels are often too unreliable and outdated to be trusted. Ideally, once there is a test to reproduce the issue, it should be ran against all maintained versions, either by a GitHub action or by whoever is fixing the issue. This will provide up-to-date and reliable info about the versions that can be trusted, and can be reflected by the already existing needs-backport-to-* PR labels. Perhaps the GitHub action could even use this information to assign and update those label automatically.
FWIW, back in the HG days I used to have ~4 local clones with different Python versions, and I would apply the patch – that usually included test + fix – on all branches, revert the fix, run the test, and if it was failing I would reapply the whole patch on that branch too. While doing this I mostly ignored the version label.
Do you have any specific example/situation in mind? Would it be enough if the versions were mentioned in a comment, where the author could clearly state if they verified/tested, or if they are just assuming?
Yes, issue templates would allow regular users to set labels, for example via a dropdown:
- type: dropdown
id: version
attributes:
label: Version
description: What version of our software are you running?
options:
- 1.0.2 (Default)
- 1.0.3 (Edge)
I was aware about the existence of templates, but didn’t know that now they also supported dropdowns and similar – thanks for sharing this! The ones I saw required users to enter information and labels as plain text in the right place and were very error prone. I also heard negative feedback about the usefulness of templates from other developers and maintainers (e.g. some users completely ignored them and wrote their report at the top or bottom, others deleted the template, others filled them in in the wrong way, etc.). For these reasons I was skeptical and wanted to avoid them, but I will now review my decision.
I think they allow entering of data in the report text from a list of values, but they don’t allow setting of actual labels (the ones you can search with via “label:xxx”), do they? Having said that, a github action could probably look for the selections from a dropdown in the issue body, and use them to set labels appropriately.
Example: I closed issues like ‘I got a compiler error on version 3.4.’ In 2022 it’s fair to ask the OP to create a new issue if they can reproduce it on 3.9+ (and nobody has AFAIK).
Rather than version tags, I’d prefer “should backport to maintenance releases” and “should backport to security releases” tags (with appropriately shorter names). These don’t go out of date and are actionable - potentially even automatable.
“Reported in version …” data is also useful, but probably only in the text of the report (i.e. through a bug template). Chances are that simply searching for version-like strings will find things well enough, and filtering by creation date also narrows down out-of-date reports, especially if we’re actively getting reporters to repro on latest versions when they report.
After migration is done, will we need to create a GitHub issue for each PR?
Actually, PRs and issues share the same tagging, notifications and total summary field, so I believe issues can be left for multi-PR epics, user reports, and questions.
I think we should keep the existing policy, where issues are required for all but the most trivial changes. This helps focus the discussion: issue discussion is about whether we should change some behavior at all, PR discussion about the exact proposed behavior.
So an issue thread is for an idea and a PR thread is about precise implementation that happens to implement this idea in full or in part, right?
I think it should be expressed in the “Create an issue…” line to prevent potential questions like “If I must to associate an issue, what should I write there?” and carbon copying of PR explainers.
More-or-less, correct. The PR is for discussing the proposed code. But implementation details can still be discussed on the issue if one is trying to figure out how best to implement something.
In response to a question by @Jelle on python/peps#2484—@ambv, can you confirm that the existing BPO links will not automatically turn into redirects and per-message linking will still work? That’s my understanding, but I couldn’t find where it was explicitly stated in either your above OP. PEP 588 (the migration plan) or the updated devguide.
Sidenote—speaking of the later, the link above is only to the top-level preview, and I couldn’t immediately spot the changed content scrolling through the (rather long and seemingly arbitrarily organized) sidebar; after several searches I found the issue tracking (tracker2) page, but it wasn’t immediately obvious to me that the referenced “new FAQ section” was in fact the sub-page titled “Github [sic] issues for BPO users” such that I thought I’d missed it; I had to dig through the PR to confirm that was actually it.
I’m not sure if this experience is enough to motivate any potential changes to the organization to expose it more, or is more specific to this particular context, but at the very least you should consider linking it (or at least the top-level issues page) in the preview link, rather than just the top level of the dev guide. Thanks!
I can confirm this: bpo will continue to work in read-only mode, and links to either bpo issues or messages will work as well. Issues will also include a link that will point to the corresponding GitHub issue, but there is no plan about adding links to individual messages from bpo to GH. bpo will also offer automatic redirects through a different URL.
Note that PEP-588 was initially proposed in 2019, but it’s currently outdated. The actual plans for the migration can be found at GitHub migration · GitHub and Migration and risk management plans · Issue #13 · psf/gh-migration · GitHub. I’m planning to convert this into an informational PEP once I complete the migration so that it can supersede PEP-588 (though I’m not sure about the details of the process).
As an advisory note, per PEP 1 and informal consensus among us PEP editors and SC members is that its better to keep PEPs focused on being change proposals rather than documentation or living specifications, and once a change is implemented, mark it as Final (with any implementation updates as needed/desired) and then add/update the canonical documentation somewhere else more appropriate, like the devguide in this case. You could also add a note at the top briefly mentioning the current status and linking to the canonical documentation, if appropriate for the PEP.
I don’t think that is true for informational PEPs in general. Those are meant to provide “information”, not document change, and if that information changes, so can the PEPs. Of course, for larger overhauls of the content, a new PEP is the better approach.
Apologies is this has been covered, but I didn’t see it mentioned in the migration guide.
Has any thought been given to applying the Experts Index to the CODEOWNERS file for auto-nosy with regards to PRs? My understanding of that file is that for PRs that have a changed file matching a pattern listed in CODEOWNERS, the associated @-mention(s) will be notified about that PR. Much in the same way as nosy-list changes on BPO, just file-based instead of label-based. I know PR != issue, but they are intertwined.
Just a though, as I have been data mining open PRs and noticed a bit of a gap in that area.
My understanding is that CODEOWNERS was rebuilt from scratch, and people have been adding themselves manually to the file. Updating the CODEOWNERS file from the expert index file is an option, however some of the names in experts.rst are not up to date and doing it from scratch ensures that CODEOWNERS only lists people that are active and still interested in being notified.
Note that the python/* repos now support label subscription, which can be used in a way that is similar to the auto-nosy. This works for both PRs and issues, unlike the CODEOWNERS file that only works for PRs (see Set up autonosy on labels · Issue #16 · psf/gh-migration · GitHub).
