Top asks from the Rules SIG of the Bazel team

[alexeagle]

Let's keep a stack ranked list of things we wish the core team had time for.

• incompatible_allow_tags_propagation bazelbuild/bazel#8830
• Notify open source contributors when patches are reverted bazelbuild/bazel#12691
• is rules_java dead? Add rules_jvm_contrib to the bazel-contrib org #27 (comment)

[keith]

We've been keeping a list of these internally as well. I'm sure it would vary a bit given the types of things folks use bazel for. For example a lot of our P1s are Android issues

[brentleyjones]

On that list, bazelbuild/bazel#12691 seems like it might be pretty applicable to most in this group.

[alexeagle]

bazelbuild/bazel#8830 also - rulesets don't typically propagate tags like no-remote-cache so we need Bazel to do it

[keith]

Here's our internal list for reference and our internal priority for them

P2 bazelbuild/bazel#10438
P2 bazelbuild/bazel#13912
P2 bazelbuild/bazel#13342
P2 bazelbuild/bazel#13839
P2 bazelbuild/bazel#13596
P2 bazelbuild/bazel#13413
P2 bazelbuild/bazel#12948
P2 bazelbuild/bazel#12691
P2 bazelbuild/bazel#12049
P2 bazelbuild/bazel#10642
P3 bazelbuild/bazel#8902
P3 bazelbuild/bazel#14008
P3 bazelbuild/bazel#14209

[alexeagle]

A broad topic: the bazel repo is home to the top-level "getting started" docs for each language, but the rulesets aren't maintained there.

JS: 2 years out of date, and no one should follow these docs:
https://github.com/bazelbuild/bazel/blob/master/site/docs/bazel-and-javascript.md

@keith are the docs linked from here still accurate? https://github.com/bazelbuild/bazel/blob/master/site/docs/bazel-and-apple.md

I think we may want to take this responsibility away from the Bazel docs site, given how hard it is to get review+merge of PRs to the bazelbuild/bazel repo. I pretty much gave up on helping to maintain those docs after waiting about five months on a trivial one-line change in bazelbuild/bazel#13382

@aiuto @philwo do you have any thoughts about the future of language-specific docs on docs.bazel.build? Does your tech writing team plan to do a pass over these at any point?

[keith]

Yea I'm pretty confident it would work, but I also wonder at this point if these examples would be better off living with the rulesets 😬

[alexeagle]

yes, that was my reasoning for removing it from bazel.build site.
https://bazelbuild.github.io/rules_nodejs/ ought to be strictly better in terms of content.
Do you already have a high-level landing page for Apple/Bazel ?

[keith]

Nope, just the readmes, there isn't really a high level tutorial at all today

[alexeagle]

Oh no... any ideas who has the knowledge needed to write it? I suppose we can use some of our SIG funding to pay someone for their time.

[keith]

It would likely have to be one of the maintainers of those repos now, or someone from google

[brentleyjones]

How about bazelbuild/bazel#14327? This is blocking rules_swift from accepting a whole slew of upstream changes.

[alexeagle]

Doing some fresh brainstorming here, and at a bit more ambitious level than what the Bazel team has historically been staffed for.

1. Skyframe. Give a way to determine affected targets given some VCS delta. Lots of companies try to use this for test selection, but the current best answer https://github.com/Tinder/bazel-diff is not correct enough (errors can slip through and be misattributed to subsequent changes when the cache is busted). Make this thing a service which is fast enough even for larger workspaces. It's in other tools! https://monorepo.tools/#detecting-affected-projects-packages
2. Engage with community PRs. Dedicate real DevRel time to shepherding changes through. Currently most companies give up on contributing back and just fork stuff.
3. Tech writing. Danielle's team has been junior and churning on the move to developers.google.com. In the meantime Bazel core docs are in really bad shape, and the ruleset guides are years out-of-date.
4. Catalog community rulesets (or contribute to the SIG so we can do it) - Sven has been trying to track which repos under bazelbuild org are abandoned. There's nothing to help users know whether they can rely on something, even if Google appears to own it. Some rulesets are on life support like rules_docker
5. Other "devrel" stuff like Jin used to do. More activity on the Bazel blog highlighting the community for example. There was a push to groom the issue backlog on bazelbuild/bazel but not on all the other repos. Probably things I don't even know that DevRel does, like Angular DevRel spent lots of time on.
6. Treat google3 as one Bazel user. For example, "incompatible" flag flips are currently gated on them becoming the g3 default, rather than just adding to the Google global blazerc and allowing the rest of the community to start benefiting from the fix.
7. Own the bazel-central-registry content in more cases rather than waiting for the community. For example, make sure that all bazelbuild/* rulesets have their latest version mirrored to the registry.

[brentleyjones]

Treat google3 as one Bazel user. For example, "incompatible" flag flips are currently gated on them becoming the g3 default, rather than just adding to the Google global blazerc and allowing the rest of the community to start benefiting from the fix.

This please. 1000 times this.

[keith]

Treat google3 as one Bazel user. For example, "incompatible" flag flips are currently gated on them becoming the g3 default, rather than just adding to the Google global blazerc and allowing the rest of the community to start benefiting from the fix.

As discussed in our last meeting I'm actively working on the doc for this proposal

[meisterT]

Out of curiosity: can you give examples of flags which you really liked to have flipped earlier but have been delayed by waiting for Google?

[zachgrayio]

yeah definitely point 1 here imo. close to 100% of the companies we've worked with have this completely wrong when we come in, even if they're fairly mature otherwise.

some docs and a fixed up version of this old script in bazelbuild/bazel (is this even in use anymore?) might be good enough as a starting point 😆 though I guess thats something anyone here can do. but yeah, a bazel affected or bazel ci would be pretty awesome in the long term

[keith]

Here's the doc mentioned above https://docs.google.com/document/d/1-OTYIXWX-600MMAnXKTuF_5u-F6GRbkHobKLBrzPizU/edit# I'm hoping to discuss in the meeting today as well

[aiuto]

To give some more context about flags for people who were not in that meeting. We came up with a concept that Bazel should have a set of "recommend" flags. These are the vision for what the next LTS release will have, and what you would recommend to someone starting a fresh project today., This is roughly the set of incompatible flags we intend to flip in the next release + maybe some experimental flags.

…

On Thu, Jan 20, 2022 at 1:18 PM Keith Smiley ***@***.***> wrote: Treat google3 as one Bazel user. For example, "incompatible" flag flips are currently gated on them becoming the g3 default, rather than just adding to the Google global blazerc and allowing the rest of the community to start benefiting from the fix. As discussed in our last meeting I'm actively working on the doc for this proposal — Reply to this email directly, view it on GitHub <#24 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHENJCDXQ2SB7EEV6ZLUXBGVXANCNFSM5JA4MTKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <bazel-contrib/SIG-rules-authors/repo-discussions/24/comments/2008828@ github.com>