Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how rules repositories are added/removed #3

Closed
alexeagle opened this issue Oct 7, 2021 · 7 comments
Closed

Document how rules repositories are added/removed #3

alexeagle opened this issue Oct 7, 2021 · 7 comments

Comments

@alexeagle
Copy link
Contributor

We'll probably host some popular rulesets in this GitHub org.

Why?

  • The SIG can be funded by donation of IP from companies, in addition to money or engineering resources
  • This can give a signal to their users that they are in a "more supported" state, as opposed to hosting on a personal org
  • We can do global janitor things to help everyone out

Before we start bringing these in, we need to decide policy bits:

  • what makes a ruleset more valuable for us to host
  • what is required of a ruleset coming in
  • what commitments do people make?
  • how do we mechanically perform the move such that everything correctly redirects
  • what happens when a ruleset wants to leave or is out of compliance with some policy
@alexeagle alexeagle changed the title Document how rules repositories intake/outtake Document how rules repositories are added/removed Oct 7, 2021
@jsharpe
Copy link
Member

jsharpe commented Nov 25, 2021

A good example for the kind of ruleset we might want to host is rules_cuda that is hidden inside tensorflow/runtime.
See tensorflow/runtime#56; I have suggested that it would be a good candidate to live in bazel-contrib as it as a ruleset clearly has wider reach than just tensorflow and there have been various forks of the ruleset overtime which all live in various personal repos in various states of maintenance.

Its also an interesting case for bzlmod as in its current form it patches rules_cc which wouldn't fit into the current bzlmod structure.

@jsharpe
Copy link
Member

jsharpe commented Dec 10, 2021

#27 is starting to highlight some of the criteria we need to establish for this.

Observations of criteria being established from that issue:

  • Convention for naming repo
  • Convention for naming workspace - suggestion is bazel-contrib/<repo_name> -> contrib_<repo_name>
  • Does the ruleset better live in a bazelbuild ruleset? Is the appropriate bazelbuild ruleset accepting external contributions?
  • Who is going to maintain the ruleset?

@keith raised the concern about "migrating everything and becoming a wasteland for low usage repos" however I think that you can use archiving of repositories to solve this to some extent; I propose that rulesets that are members should ensure support for LTS versions of bazel and that we should (with some notification and grace period) archive anything that doesn't meet this criteria. I think this would provide a clear mechanism to users to know which repos are actively supported but without breaking anyone by removing repos from the github org.

@alexeagle
Copy link
Contributor Author

"who is going to maintain" - this also begs the question, what reputation does this person have, and do they have an employer backing the repo with other engineers to replace this person when they eventually move to another project? @shs96c certainly has an excellent reputation in the Bazel community for example. But how do we tell that without being biased or exclusionary?

"ensure support for LTS versions of bazel" and "actively supported" is the hard part. How can we tell? Maybe we require that rulesets have some bazel-in-bazel integration tests that ensure the compatibility, but we don't really know if there's good coverage. If users file issues and the maintainers don't respond in X months does that mean we archive the ruleset?

The SIG has some funding now, so if someone has a couple hours to write up a document they could bill for that time.

@nkoroste
Copy link

nkoroste commented Jan 25, 2022

Criteria for accepting rule sets into this repo and avoid them from getting stale:

  1. Must have a clear owner (POC)
  2. Must have clear readme outlining the goal of these rules, how to use them etc.
  3. Must have examples
  4. Must have tests that are running continuously
  5. Must have an SLA of replying to issues/PRs in 2-3 weeks (exact timing TBD)
  6. Must have at more than one person who are committed to review/approve PRs? Encode as a CODEOWNERS file.
  7. Must publish semver releases. Optional: follow the same release pattern as the rules-template does

@keith
Copy link
Member

keith commented Feb 8, 2022

I think this is a good list. I think we should also codify the failure cases for this, because realistically without directly funding folks we won't really be able to hold them accountable to specific SLAs long term, and folks could leave the projects at any time, leading to us needing to find new maintainers, or archive the project etc.

@alexeagle
Copy link
Contributor Author

  1. Needs to work with LTS Bazel version
  2. Include the rules in bazel-central-registry, keep that CI green

When something no longer meets the criteria:

@cloudhan
Copy link

@jsharpe Now I am developing a pure starklark implementation for cuda rules. Just FYI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants