We have quite a few track repos that are marked WIP and haven’t seen any work towards launching in a year or two. Yet, these tracks manage to add maintenance overhead in the form of PRs. This includes dependabot version bumps, cross-track improvements (fixing common issues like incorrectly formatted markdown files, adding standard bin tooling, syncing files from the problem spec, and more).
A small few have been archived (babashka, clojurescript, gnu-apl, z3). That leaves quite a few still open (including clojurescript-test-runner).
I propose archiving those repos, along with their associated tooling repos ($slug-analyzer, $slug-representer, $slug-test-runner) until such a time that we have an active maintainer for them. (Repos can be unarchived.)
As a secondary measure if archiving is not desirable, I propose disabling dependabot for the above repos.
I think we’ll some insight about how that might affect the terraform scripts for repos that are (or have been) live (like plsql).
But I appreciate the initiative. As someone who jumped into maintaining the Forth track without understanding the language, I’ve been irritated by the dependabot PRs
I think I’m missing something here. What problem are we trying to solve? A WIP track shouldn’t require PR reviews period until it goes live. So if it’s inactive, that’s just deferred maintenance for the next person who starts working on the track. I think that’s reasonable to expect if you’re picking up a stalled WIP track.
A WIP track shouldn’t require PR reviews period until it goes live.
A WIP track generates work, per the above. There are stalled WIP tracks that people are putting time into maintaining.
Yet, these tracks manage to add maintenance overhead in the form of PRs. This includes dependabot version bumps, cross-track improvements (fixing common issues like incorrectly formatted markdown files, adding standard bin tooling, syncing files from the problem spec, and more).
The PRs may not need a maintainer to approve, but they still create work and use time and energy. If the track is WIP and stalled, that time and energy is not well utilized when spent on that track.
So if it’s inactive, that’s just deferred maintenance for the next person who starts working on the track. I think that’s reasonable to expect if you’re picking up a stalled WIP track.
If there is a new track maintainer, archived tracks can be unarchived, allowing all the above work to resume. If a stalled track is never picked up, the above work isn’t a good use of time.
Yeah, I’m still missing the big picture here. How are you doing maintenance if you’re not already the maintainer with write access? Are you getting special privileges as a guardian? As a cross-track-reviewer, I don’t have write access to WIP tracks so I can’t do maintenance even if I wanted to. The disconnect for me is that as presented, this seems like some folks are taking it upon themselves to do maintenance when they might not need to.
I can see the benefit in archiving deployed tooling images if they’re stale WIP tracks. Chapel in particular is pretty heavy. However, that has more to do with saving money on test runner deployment than any maintenance concerns.
This includes dependabot version bumps, cross-track improvements (fixing common issues like incorrectly formatted markdown files, adding standard bin tooling, syncing files from the problem spec, and more).
Dependabot PRs ping guardians and cross-track maintainers.
Manually created PRs are typically community contributions where someone found something to update or broad cross-track updates (eg add a bin/run-in-docker.sh to all tooling repos that lack it, or fix headers in all instructions.append.md files).
That aside, I’m fine with archiving old track repos especially since there’s a precedent here but after we clarify whether there might be any side effects like what Glenn said.
Pings or not (configurable many ways), there are PRs that are opened, reviewed and merged The commit history shows that to be true. Those PRs take time and energy.
Yeah, I understand that now. I was fixating on the ping part since I thought the problem was cross-track-maintainers and guardians were being asked to do something outside their defined scope. It’s more someone at some point will need to do this maintenance. If the track is archived, it’s a clear sign nobody is working on it actively, and we can judge from the archival date if we were to unarchive it, approximately how much work might be needed to bring the track back up to speed.
@ErikSchierboom Would it make sense to archive tracks that are unlaunched, unmaintained and stale (along with their tooling repos)? Does archiving a repo have any impact on the Terraform tooling?
Yeah I think we’ve done that before. We can always unarchive. As for the terraform tooling, if there is tooling that we deploy for those tracks, we should remove them from the terraform scripts.
The commit history shows that to be true. Those PRs take time and energy.