[Release] Cut a new release (7.1.1) or retrigger 7.1.0

[FrankPortman]

Right now, 7.1.0 is not actually on Bazel Central Registry due to some issues that came up during that process. Those have since been fixed (I think), but the process either needs to be retriggered, or 7.1.0 should be "yanked" and 7.1.1 released. As it stands, the instructions in the 7.1.0 release are incorrect since 7.1.0 doesn't actually exist on BCR.

[mbland]

Since bazelbuild/bazel-central-registry#5490 is based on the 7.1.0 tag, I think we'll need a new 7.1.1 tag. Specifically, I don't see how we can get that PR to pick up #1761 without reassigning the tag, which I don't think is a great idea.

I don't know that we need to yank 7.1.0, though, since it never made it to the BCR. Some legacy WORKSPACE users may be using 7.1.0 with no problem. However, a maintainer can edit the 7.1.0 tag description to remove the Bzlmod instructions.

---

Also, not to digress too much, but @simuons and @liucijus what do you think about adding the jobs from .bcr/presubmit.yml to .bazelci/presubmit.yml? It's a bunch of jobs, but they run relatively quickly, and they caught a real problem. It would be nice to include them in our regular CI, but I'm open to alternative suggestions or arguments to the contrary.

[BillyAutrey]

@simuons @liucijus can we have a conversation about long term maintenance? I know several folks active in Scala and OSS that we can safely add to maintainers, and who actively contribute to this rule set today.

[simuons]

@FrankPortman I'll push 7.1.1 tag shortly.

@mbland regarding .bcr/presubmit.yml: if this helps to catch problems sure we can have those. Thought my concern is that we would need to sync it periodically to not to diverge from bcr or I misunderstood something.

@BillyAutrey sure let's have a discussion either here or in slack. I thought about it myself, that it would be healthier for rules_scala to have more maintainers. Please share who you have in mind as possible maintainer and let's invite them. I have one person in mind who is here in this discussion :)

[BillyAutrey]

@simuons thanks so much! In the interest of free/public information, I'll post my thoughts here. I'll also ping you on bazel slack.

Possible maintainers:

• @WojciechMazur (or one of his colleagues at VirtusLab) would be a good candidate. VirtusLab is active in the Scala OSS community. They contribute to metals, Scala itself, and more. Wojciech has contributed recently to this repo. @romanowski for visibility, or other nominations.
• I would like to be considered as well. I've contributed to this repo, I currently work at EngFlow (a company heavily invested in the Bazel ecosystem), and I am active in the Scala community - currently helping with the PlayFramework and sbt plugins towards a 2.0 release.
• @mbland is of course a good candidate as well, he's a colleague of mine at EngFlow. He's done some major heroics here to get bzlmod support.

Thoughts on moving forward:

• I would like to consider the proposal Lucid dropped in bazel slack, and discuss as a group which things we would like to incorporate.
  • E.g., Zinc has historically been contentious - but the tool has changed since Oscar's comments back in 2018, and it is worth re-evaluating in non-incremental mode.
• I know of other companies that have forks of rules_scala. Considering their reasons for forking, and merging the best parts, might unify company efforts and improve the health of this rule set.

[BillyAutrey]

@eed3si9n might also be worth considering, he's the key maintainer of sbt - but also active in the bazel community. I'll let Eugene speak for himself if he wants to join this party or not.

[mbland]

@mbland regarding .bcr/presubmit.yml: if this helps to catch problems sure we can have those. Thought my concern is that we would need to sync it periodically to not to diverge from bcr or I misunderstood something.

@simuons It shouldn't diverge in the sense that the jobs from .bcr/presubmit.yml are essentially the test_cross_build_example test case from test/shell/test_examples.sh multiplexed across multiple Bazel versions and operating systems. Both are running bazel build //... in the examples/crossbuild module (though the BCR presubmit jobs also running bazel test //...). I'll cook up a pull request.

@mbland is of course a good candidate as well, he's a colleague of mine at EngFlow. He's done some major heroics here to get bzlmod support.

@BillyAutrey I appreciate the nomination, but two things.

First, a personal nit, not an attack: I performed no "heroics." I perceived an opportunity to contribute, and my (well, our) employer supported that pursuit. From there it was just solving one problem at a time until the job was done. I believe we apply the term "heroic" to software development too loosely, and I consider that dangerous to the individual, an organization, the industry, and the public. "Well done" is sufficient.

So I very much appreciate the sentiment and the recognition, but I want to squash the illusion that there was any special effort or courage or any other extraordinary element at play. I only enjoyed solving this specific problem so much that I stuck with it for a while until I got it done. I also had a lot of help along the way, from my (our) employer's support to direct assistance from the maintainers and others invested in the success of this project. That wasn't heroics; it was teamwork.

Second, while I've become well versed in Bazel compatibility, I'm a Scala amateur. I'd have to defer to actual Scala experts to validate the details of the intended outcomes of the Starlark implementation. If that's a satisfactory degree of contribution, then I'd be happy to participate as a maintainer in that limited capacity.

[BillyAutrey]

Second, while I've become well versed in Bazel compatibility, I'm a Scala amateur. I'd have to defer to actual Scala experts to validate the details of the intended outcomes of the Starlark implementation. If that's a satisfactory degree of contribution, then I'd be happy to participate as a maintainer in that limited capacity.

I enjoy a diversity of opinion and skill. I feel that the skills of everyone I suggested will complement each other, and will result in a wide base of experience. That base will become the foundation on which rules_scala can thrive, if we collaborate continually. Teamwork, as you say.

[eed3si9n]

I've been using rules_scala at multiple workplaces, somewhat passively. I'd be happy to join the party if Scala or Zinc information I have can be of use.

[romanowski]

@BillyAutrey Thank you for the tag. I spoke with @tgodzik from our OSS Scala team, and he and his team are happy to help maintain rules_scala. We work on bringing Bazel into the mainstream of the Scala community, and we can start by ensuring that rules_scala works with new versions of the Compiler before the stable version is released. In short, @tgodzik may be another person to consider for the new, expanded group of maintainers.

[mbland]

@FrankPortman @simuons FYI, rules_scala 7.1.1 is now available in the Bazel Central Registry. (And thanks for that, @simuons!)

Should we close this issue and open a new one for the maintainership discussion, or keep it open (and maybe change the title)?

[simuons]

I’ll go ahead and open a new issue. I hope it won't cause too much confusion or noise, since this issue is about a different matter.

[simuons]

I'm closing this as 7.1.1 was released and let's move maintainership discussion to #1765