This is a good point to bring up. I think we should probably go the other direction though. I think that if a package is broken we should try contacting the maintainers of the dependents next. Because their packages will be transitively broken if the issue isn’t resolved. Also pushing packages upstream is a recipe for having the maintainers of “core” libraries and tools slowly getting more and more packages pushed upon them and them getting overloaded. I don’t want the maintainers of our most critical derivations to become a dumping ground for unmaintained packages.
This does raise the question about leaf packages. We can consider doing the following things:
- Don’t let them block and other changes, they quickly get marked as broken.
- Notify anyone who has changed the file.
- We might want some systematic way to filter out tree-wide changes.
- Notify the maintainers of dependencies or other related packages and ask if they are interested in maintaining the package.
But at the end of the day if the maintainer of a leaf package leaves I think we just need to let it wither (marked as broken) and we should probably periodically sweep broken packages from the repo.
This also doesn’t specify how we determine if a maintainer has abandoned a package. It would be nice to have some sort of automation around this as well. However if we see they have been inactive for an extended period of time (1 month?) we can remove them from packages. Worst case they are on an extended offline period and can revert the PR to claim their packages back.
I think PLEASE fix ALL packages which were broken by the Qt-wrapping-changes - #20 by timokau is the right call. I think that we need to define some policy around this (submitting an RFC is high on my dependency list for the merge queue). I think marking things is broken makes sense and would want to define some sort of standard workflow around this. For example take the following option as a base example for changes that break more dependents than you can, or wish to fix yourself.
- The breaking PR is reviewed, but not merged. (The merge queue bot wouldn’t allow it anyways)
- The PR branch is now “the staging branch” for this breaking change.
- Once it is approved maintainers of any broken dependents are notified.
- They are expected to respond to the breakage. They should create a fix and merge it to master, if it is backwards compatible, or to the staging branch.
- After at least 1 week the any unfixed packages are marked as broken.
- At this point the staging branch should be “green” and is merged.
To me this sounds like acceptable overhead for the “parent maintainer” assuming that we can mostly (or completely) automate sending notifications and marking packages broken.