Should we have separate way to track/file issues for PEP infrastructure?

Core Workflow
1

The PEP infrastructure has undergone quite big changes lately, and the infrastructure seems to be a large project on its own.

Maybe some of us may want to be able to be able to subscribe to just the changes related to the PEP texts itself, and not the infrastructure part. Wondering if this is something that can be separated somehow?

Perhaps issues related to the infrastructure can be discussed in the core-workflow repo (and PR in the PEPs) repo? Or does anybody else have other suggestions?

2

Tagging should work. It is possible to subscribe to tags both in Discourse and on GitHub.

3

Can you describe in more detail what you mean?

4

It would be great to have a way to somehow separate the two, so people could pick which they were subscribed to. There are a few issues with doing so on a separate shared repository, though:

  • Most of the volume has been in terms of PRs and comments/commits/etc. on them, which would still have to happen on the PEPs repo
  • With a shared repo, everyone would need to be diligent about always tagging PEP-related issues with a particular tag all the PEP infra people were subscribed to (or @ the team on all of them)
  • Header updates, technical/syntax fixes, minor proofreading, and other non-substantive PEP changes still wouldn’t be separate

The first two issues could be addressed by moving both the issues and the PEP infra code to a separate repo and making it a submodule, but that would entail a ton of churn and complexity.

What I’d suggest instead is piggybacking on our existing system of GitHub labels; we already use them for infra, meta, lint, etc changes and we could add a pep-content or similar label (we already have a new-pep one for PRs adding new PEPs), which people could then subscribe to (since GitHub just rolled out that beta feature and its enabled for us, and is should be improved further). You could then choose to only be notified of new PEPs, PEP content changes, infra changes, etc. or any combination.

5

I don’t think it would be that much churn. We can discuss at the docs meeting if time, but I’m happy to separate the infrastructure to an ‘other’ if it is deemed appropriate.

A

6

I am a very unsophisticated GitHub user. I want to watch the peps repo to make sure a rogue editor doesn’t start changing PEPs (and I’m a repo admin to provide continuity). But at the same time I’m not interested in reviewing the infra issues. One thing, perhaps requesting review from “peps-editors” is not the right thing to do?

2 Likes
7

Yeah, but the infra is still coupled enough with the content on a practical level that splitting them up makes a number of things more complicated for both PEP editors and PEP authors:

  • PR authors (and editors) need to be able to build locally with the current version of the repo. Making it submodules, or structuring it as a Python package and installing from PyPI/GitHub add extra steps and pain points both for PEP authors setting up a new environment, and every time there is any infra changes.
  • The linting, GHA config and other infra besides the Sphinx extension still needs to be in the PEPs repo
  • Changes that involve both changes to the infra and to PEP 1/12, existing PEPs or docs (which is many of them) require two seperate PRs, despite depending upon one another and being one atomic change. And how to split up the docs, README, contributing guide?
  • Also, the nominal focus of PEP 676 was making the PEP building “self-contained” in the PEPs repo, which this would reverse

It also still doesn’t separate the technical changes to PEP (e.g. PEP authors updating their PEPs to point to a new discussion thread or fix a minor issue) from the substantive (adding a new PEP or making content changes to one).

And the pace of changes to the core infra should slow down pretty soon, as the new implementation stabilizes and the changes people have requested get resolved.

True, someone might not label their PR, but right now there’s nothing stopping anyone with merge permissions from just committing whatever they want to the repo directly, which AFAIK doesn’t result in any notifications at all anyway (at least without stricter branch protection rules, which we could have but might cause some pushback) :smile:

To watch specific labels, you just click the “Watch” button, click “Custom” and select the tags you want, and GitHub is working on improving the UI/UX at the moment.

8

Where are the labels used in this repo documented? And how consistently are they being used?

9

In the Contributing Guide as matching title tags and with concise :wink: descriptions in the labels menu and labels list. We could document them more formally if you prefer, but I wanted to keep them lightweight and avoid setting the expectation that PR authors are need to worry about them unless they want to.

Of the 9 infra/meta/lint PRs in the past two weeks, 8 were labelled as such on creation or before being merged, and the 9th was merged less than three hours after being opened and I applied it after (though a notification is still sent). This should improve once @Jelle and @AA-Turner are aware of the labels (since I just added them recently), assuming we want to continue them.

Even if it isn’t 100% perfect, it is not really any more than the status quo—any core dev or PEP editor can unilaterally commit to the repo (with no notification) and merge PRs immediately (with notification after merge), the latter case being the same with post-merge labeling. Discussing issues on another repo only cuts out a fraction of the infra notifications, and separating the entire infra is much less lightweight for both PEP authors and editors, while a fair amount of linting and meta-related changes, not to mention minor PEP updates, will still have to be on the PEPs repo.

10

Is this a feature github rolled out specifically for CPython? I don’t see it on other repos

11

My understanding from talking with @erlendaasland about it today at the PyCon sprints is that it is a beta feature GitHub has just rolled out that is enabled for the Python org repos, and will be further improved and deployed for all users in the near future. As to whether it was specifically motivated in response to a feature that would be missing after the BPO migration, I’m not sure; you’d have to ask @ezio-melotti or someone else more knowledgeable about that.

12

That’s correct. We have a few beta GitHub beta features enabled for the python org, some of which were requested specifically to replace BPO features.

3 Likes
13

@ezio-melotti (or others who know)

Can you “unwatch” a specific label? I.e. someone in Guido’s situation where he cares about most of the events in the repo, but can safely ignore changes labelled as “infrastructure”.

A

14

As far as I know this is not possible, however it should be possible to select all labels except the one you don’t want to watch.

1 Like
15

The issue there is unlabelled events — but we could add a ‘PEP edit’ label or something, I suppose.

Is there a way to suggest following-by-exclusion to GitHub?

A

16

Yes, I just reported the suggestion to GitHub.

1 Like
17

Yep, that’s what I’ve proposed; this could also filter non-substantive technical updates, like discussion thread links, and minor textual fixes.

The issue with that is how would it handle situations where an issue/PR wasn’t initially labelled, but it was quickly tagged by a triager/editor/etc. after being submitted—would the user be unsubscribed and the initial notification automatically removed?

18

Currently, label subscriptions seem to be handled separately from regular subscriptions. Being subscribed to a label triggers emails notifications, but doesn’t automatically subscribe you to issues/PRs that have that label (you can verify this by looking at the “subscribe” button on the right).

This will depend on how they are going to implement the feature (assuming they do). I guess that the notification might be sent or not simply depending on the combination of labels and label subscribers at the time a new message is posted to the issue/PR.

2 Likes