Archiving rulesets that have gone unmaintained

[alexeagle]

Hey everyone,

As part of the rules authors SIG, we've been cataloging rulesets and determining which ones are no longer maintained at all.

Last week I suggested to the Bazel team that we archive https://github.com/bazelbuild/rules_k8s after we confirmed that none of the committers were doing any maintenance for the last several years.

I'd like to propose a process around this for the bazelbuild GH org, similar to the one used by the bazel-contrib org: https://bazel-contrib.github.io/SIG-rules-authors/hosting-policy.html#archiving-a-repo

1. periodic audit of bazelbuild/* repositories
2. Those which seem unmaintained, we do an outreach to prior committers and those with write access to the repo to confirm whether they are still maintaining
3. If there are no maintainers, give the community an opportunity to adopt. This requires some measure of "what work is needed" and then "make a public commitment to doing that work". (It would not help to get volunteers who take a maintainer role and are quickly overwhelmed, and/or don't have buy-in from whoever they're accountable to for their time)
4. Reach out to maintainers of any rulesets that depend on the unmaintained one, so they have an opportunity to react. (e.g. if they want to cut the dependency, take over the dependency themselves)
5. Archive the repository. This is the step where more people will notice, since we are all busy and wouldn't read communications from the prior steps. In the README, point to this discussion, since the archived repo is read-only so issues there can't be active.
6. The repository can still be un-archived if new maintainers arrive.

[jsharpe]

I think also an assessment as to whether the ruleset is used by any other rulesets would be a good idea as archiving a ruleset that others depend on should at least be flagged in the downstream repos.

[alexeagle]

Yes, that is a good point, I'll note that in the proposal. I would hope that maintainers of a ruleset are taking care of the dependencies they take - as another less-severe example, a 1.0 stable ruleset should probably not depend on a 0.x pre-release ruleset (assuming some consistency about what semver means across the rules ecosystem)

[alexeagle]

https://github.com/bazelbuild/rules_postcss is the least-recently touched

• in Release to be compatible with NodeJS 14+? rules_postcss#73 (comment) @sventiffe said it would be archived nearly a year ago
• the last communication I saw from the author is on the latest issue Update rules_nodejs to 5.0.0 rules_postcss#74 (comment)
• @tjgq is the most recent committer - could you please double check if anyone is maintaining?

[jsharpe]

rules_gwt? - bazelbuild/rules_gwt#39 this seems like a candidate too?

[alexeagle]

Sure, do you mind making a separate thread for that?

[alexeagle]

@rzhw FYI I'll post on Bazel slack about this thread and see if there's community interest in becoming maintainers, if that's okay with you.

[rzhw]

No issues here, @nex3?

[rzhw]

Got it archived @comius

[sluongng]

It would be nice to leave a grace period before archiving to notify folks (via README and/or a pre-archive release) to give them a chance to take ownership. Ownership here mostly means somebody could fork and we can leave a line on the README.md before archiving to point newer folks to the fork. 🤔

I think there are a few orgs out there that use rules_k8s and may want to continue maintaining it via an internal fork. Having that process would encourage them to opensource the internal fork.

[alexeagle]

You can still fork an archived repo, such as rules_k8s, if you intend to maintain a private copy in your org. But I understand the point if you want to make a canonical, public fork for everyone, or take over the existing repo in bazelbuild org.

I think it's likely that a person in that situation just won't see the notification you make during the grace period, but is more likely to notice after the repo is archived.

[alexeagle]

https://github.com/bazelbuild/rules_webtesting

• Last release was 18mo ago
• 3 commits in the last 6mo
• @joshbruning had the last "maintainer-looking" issue comment Flag --incompatible_config_setting_private_default_visibility will break rules_webtesting in Bazel 7.0 rules_webtesting#446 (comment)
• @devversion and @dgp1130 are the most recent community experts answering issues, do you know who is maintaining?
• @juliemr - my understanding is your team doesn't maintain this anymore?

[juliemr]

Correct, I don't think we're the right maintainers anymore.

[meteorcloudy]

@alexeagle Thanks! The bazelbuild org definitely should have such a process, another point I want to add is that, if we archive an repo under bazelbuild and someone from the community want to revive the repo, it's worth considering reviving the repository under bazel-contrib.

@radvani13 WDYT? Can you help with implementing such a process?

[alexeagle]

We tried that once (with bazel-integration-testing) but at the time we ran into a policy wall: Google owned repos weren't permitted to be transferred out. We can try again though!

[cgrindel]

To @meteorcloudy point, "revive" could just mean fork the repository or just copy the files into a new repository. Either way, I support resurrecting these repositories under bazel-contrib.

[meteorcloudy]

Exactly, forking should be fine, we'll lose all issues and PRs, but I guess it's OK.

[jsharpe]

bazelbuild/rules_gwt

• No one has responded to this issue Stakeholder Reach-out: Is this project maintained? rules_gwt#39
• No activity since 2020, except bazel CI maintainence.
• CI is broken with latest bazel Remove rules_gwt from Bazel CI continuous-integration#1202
• @ekuefler do you have any opinions on the status of this ruleset as you're the last meaningful commit?

[sluongng]

We might want to update

bazel/src/main/java/com/google/devtools/build/docgen/templates/be/be-toc.vm

Line 28 in 1b00db9

- title: AppEngine

as well to avoid pointing newer folks to deprecated rules.

[meteorcloudy]

Good point! I'm also happy to review a PR ;)

[chrislovecnm]

I would add:

• https://github.com/bazelbuild/rules_sass
• https://github.com/bazelbuild/rules_jsonnet
• https://github.com/bazelbuild/rules_d
• https://github.com/bazelbuild/rules_perl

One thing of note. Bzlmod is here soon. Should we open issues and maybe note in the README that we need bzlmod support?

[alexeagle]

Let's keep bzlmod orthogonal, it's just one of many things a ruleset needs from its maintainers.