Bazel
Transfer community maintained repositories to bazel-contrib #2
Replies: 10 comments 31 replies
-
Beta Was this translation helpful? Give feedback.
-
|
/cc @jheaff1 who is also a rules_foreign_cc maintainer |
Beta Was this translation helpful? Give feedback.
-
|
What are the functional differences, if any, between being in the bazelbuild versus bazel-contrib organizations? I'm thinking of things like access to Bazel CI and what repository configuration options are available to maintainers. |
Beta Was this translation helpful? Give feedback.
-
|
Currently most (all?) repositories under bazel-contrib use GitHub Actions for CI rather than the Buildkite-based Bazel CI. I don't think it's been an impediment, but it does mean those rulesets are not considered when Bazel core is rolling breaking changes to their "downstream pipeline". So using Bazel CI might make sense for more bazel-contrib rules. OTOH it's nice to be independent of Google, not worry about how many Mac machines are available in a Google datacenter, or the 5am-European-time brownout when they run their nightly jobs. |
Beta Was this translation helpful? Give feedback.
-
|
All projects using Bazel CI can continue to do so, nothing would change, I added a "Transfer Process" section to the post. |
Beta Was this translation helpful? Give feedback.
-
|
It's a bit weird to see rules_go, gazelle, and rules_proto are being moved out, but rules_python and buildtools are staying in. It's also unclear to me what problem are we solving for these projects. And whether the problems outweigh the churn when the entire community has to switch from 1 namespace to another. Recently we had a similar transfer for |
Beta Was this translation helpful? Give feedback.
-
I read this as: Google no longer supporting these projects. Which I think is fair. However, I did highlight that some projects such as rules_go and gazelle are core dependencies of some Google OSS projects. It's a bit backward to see these being dropped to community-supported status instead of the reverse: being elevated and staffed with Google engineers. We have seen this done with rules_rust, rules_python recently, which is why I don't see them on the list here?
Who will help with the lift and shift? Are we taxing the existing community maintainers to make this happen? Or should Bazel team/Rules SIG help out with the transition?
Realistically, we have had Rules SIG putting bounties for work done within Bazel.git. I would love to hear more regarding how maintainers and users of each impacted project would benefit from these "funding opportunities" as a result of the namespace change though.
This sounds like the main motivation here. How does this translate? @meteorcloudy I don't think this is a strong reason/benefit to motivate the move. I was expecting something more like: Org X is looking to sponsor rules_go with Y minutes of CI, but was unable to do so if the project is under I wonder if we are aiming to solve the right problems here. |
Beta Was this translation helpful? Give feedback.
-
I think here are the more clear expectations, I'll add them to the main post:
I do hope relevant Google teams can elevate their support on open source Go rules and will reach out to them, but even that's true, that doesn't mean they cannot support the project under bazel-contrib. Google OSS projects will always have third party dependencies we don't fully control, and that's fine.
I don't think the transition will be super disruptive and the Bazel team and Rules SIG can definitely help. It sounds like you might think this is a very costly process for go maintainers? Do you have any specific concerns?
Fair point, but if they project is located under bazel-contrib, it'll make it easier to justify the funding and less worry about Google not responding to the contributions.
But the goal of the Rules Authors SIG and the future foundation is to better support the project maintainers and provide better experience to Bazel users, right? |
Beta Was this translation helpful? Give feedback.
-
The underlying technology of Go and Proto are owned and used by Google. These rule sets often need to be updated before or soon after a new version of the underlying technologies is available, so Google controls the direction of these rule sets in some ways. I hope Bazel team can overcome the bureaucratic barriers some day and have Go and Proto teams support these rule sets. Moving rules_go and rules_proto to bazel-contrib sends a message to the community: Google supports Bazel, Go, Proto individually, but doesn't support their integration and has no plan to support it in the future either. Is Google is still planning to replace internal Blaze with open source Bazel in the future? If so, those rule sets can be synchronized to Google's internal codebase too.
The expectation can be set with a big bold sentence at the top of the README of these projects, which requires less change than moving them to a different org. |
Beta Was this translation helpful? Give feedback.
-
I think it's intentional to send that message, because it's accurate. I can't speak for the Go team's plans, but I did discuss with protobuf team at length about it. |
Beta Was this translation helpful? Give feedback.
-
I believe it's totally fine that the toolchain and the Bazel rules are maintained by different parties. This is actually true for most of rulesets.
I don't think that would happen in the near future. Even if it does, Google will probably keep using the internal version of Go rules instead of migrating to the open source one. And +1 for sending the correct message that matches the reality. |
Beta Was this translation helpful? Give feedback.
-
|
From rules_dotnet perspective the only thing I'm a bit worried about is switching from Bazel CI to Github Actions. What I like about Bazel CI is:
I think that it could be considerable effort to migrate form Bazel CI to Github Actions to maintain the same coverage. |
Beta Was this translation helpful? Give feedback.
-
|
@meteorcloudy I think we could quickly setup the GitHub permissions and demonstrate a project under bazel-contrib that uses Bazel CI, to alleviate this concern. I know Bazel CI doesn't want to accept new workloads [1], but it should be an easy case to make that existing workloads are allow-listed. [1] I couldn't find a reference for this, bazelbuild/continuous-integration#1135 seems like it should mention what new projects you currently accept |
Beta Was this translation helpful? Give feedback.
-
|
Likewise for rules_foreign_cc - there is very little maintainer time available for this so sucking that up with a migration of CI to github actions will be detrimental to the maintainability of that ruleset. |
Beta Was this translation helpful? Give feedback.
-
|
I added a "Transfer Process" section to clarify this. Projects currently using Bazel CI can continue to do so, the Bazel team will help update CI configs. |
Beta Was this translation helpful? Give feedback.
-
|
How would this migration work process-wise? Would each of the migrated repositories go through the "Adding Procedure" on its own? Or would there be a bulk onboarding for all repositories? |
Beta Was this translation helpful? Give feedback.
-
|
Good question, added the "Transfer process" section to explain this. |
Beta Was this translation helpful? Give feedback.
-
|
Do you already have a rough timeline for this move? Are you planning to execute on this plan already within the next weeks? Still this month? Next month? |
Beta Was this translation helpful? Give feedback.
-
|
I'm still not sure how long the internal approval process would take, the estimate is at least several weeks and I'll be out of office in most of May, which could slow things down a bit. So my best guess is late May or early June. |
Beta Was this translation helpful? Give feedback.
-
|
What about https://github.com/bazelbuild/tools_remote? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I might have missed that one, @bergsieker any objection?
I think that's definitely possible. We can discuss the details when we actually start the transfer. |
Beta Was this translation helpful? Give feedback.
-
|
FYI. That can cause some headaches for the clients of the repository. When toolchains_llvm moved to That being said, if a name change was desirable, perhaps we could take a different tact. The repo could be forked to |
Beta Was this translation helpful? Give feedback.
-
|
I'm aware of the disruption toolchains_llvm caused (and was impacted by it). Still it's the preferred move, and I'd prefer to have an actual redirect as I expect we'll receive from bazelbuild/bazel-buildfarm -> bazel-contrib/buildfarm than a manual jump from a dead repo location. Willing to take the hit on impact for clients. |
Beta Was this translation helpful? Give feedback.
-
|
No objections to moving tools_remote to bazel-contrib. I also agree that changing bazel-buildfarm to buildfarm makes. Buildfarm is essentially independent of Bazel, is expected to work with RE clients beyond Bazel, and has been owned and maintained by werkt essentially from inception. I have no opinion on the technical issues that move might create. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I updated to post to include tools_remote as well! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the "benefits" section @meteorcloudy. Could you further elaborate on the tradeoffs for making such a move, which includes the known costs (or what will the projects be giving up - perhaps Kythe indexing on I think there's another point to be made about no longer requiring Google CLA in |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Done, thanks for the suggestions! |
Beta Was this translation helpful? Give feedback.
-
|
Update: The transfer of the listed repos has been officially approved by Google. We'll follow up with project maintainers to execute the transfer repo by repo. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hi folks. Is it expected that https://bazelbuild.github.io/rules_foreign_cc/ is a 404? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like it's now https://bazel-contrib.github.io/rules_foreign_cc, github didn't offer redirects for everything. /cc @jsharpe |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, not a lot we can do about that because if we created a replacement placeholder repo in bazelbuild to setup a redirect site you'd loose all the other redirects.. |
Beta Was this translation helpful? Give feedback.
-
|
aspect-build/rules_js#1931 for example - all these repo moves may result in broken GH pages links :( |
Beta Was this translation helpful? Give feedback.
-
|
Yes it is; but why not redirect?
…On Mon, Oct 7, 2024 at 12:32 AM Yun Peng ***@***.***> wrote:
Looks like it's now https://bazel-contrib.github.io/rules_foreign_cc,
github didn't offer redirects for everything. /cc @jsharpe
<https://github.com/jsharpe>
—
Reply to this email directly, view it on GitHub
<#2 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB4GME7DTUFDFRD73O64Y3Z2I2KHAVCNFSM6AAAAABGATUQY6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBWGQYDMOI>
.
You are receiving this because you commented.Message ID: <bazelbuild/.
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's a GitHub bug. GitHub pages sites don't get the same redirections that |
Beta Was this translation helpful? Give feedback.
-
Since Bazel was open-source in 2016, the Google-owned bazelbuild GitHub organization has hosted a growing number of repositories for the Bazel ecosystem, including Bazel rules, IDE plugins, and remote execution backend. However, many of these repositories are no longer actively maintained by Google teams and rely more on community support.
The Bazel Rules Author SIG was founded in 2021 and governs the bazel-contrib GitHub org. Since then, it has been a home for many Bazel relevant projects, guided by a clear hosting policy. The SIG has also been supported by the community via Open Source Collective and probably by a future open source foundation.
To ensure better maintenance of those projects, we want to migrate the community maintained repositories to bazel-contrib. A repository is a suitable candidate for the move to bazel-contrib if all of the following conditions are met:
The status of all bazelbuild repositories are summarized in this spreadsheet, with the above standards, we have identified a list of repositories that could be moved to bazel-contrib:
Benefits
Transfer Process
Costs
Alternative
This discussion is to gather feedback from the community. Please let us know if you think any repository should or should not be moved to bazel-contrib!
Beta Was this translation helpful? Give feedback.
All reactions