You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Top level request: Can we have a single document which explains the requirements for publishing a BCR entry for a module which brings in a new well-known library into the BCR?
It's not obvious to me that the overlay method is the recommended way to provide a module.
Might as well be. But if it is, it would be nice to have a document that says as much, and explains the expected workflow we're supposed to follow.
I observed that so far the approach has been governed by "case law", but is there a reason now to not write it up somewhere? If there was a BCR publication checklist, I'd be more than happy to read it and follow it.
If indeed the overlay method is recommended, I have not seen any explanations how one would practically go about it.
I understand how to publicize an overlay should one decide to do so. But it's unclear to me how this is automatable. As far as I understand the current status is: you have files to overlay, you have the library source, good luck.
Instead, it would be nice to have a preferred workflow description that a would-be contributor could use.)
If jemalloc@5.3.0-bcr.3 #8202 (comment) is indeed case law, it seems to me that if supply chain risk is a worry (understandable), attestation is the entry level requirement, not homepage.
However, not clear to me how not pointing a link at the place where the BCR additions live help make the supply chain case. I actually have the opposite problem with BCR overlays: that the overlay additions are somewhat not front and center, even though they are just as powerful in terms what they can do to the end result as is the library source itself.
Last but not least, //docs seem unwieldy.
Maybe not so much to a trained eye... But: it is not clear to me which of them a contributor should read so that they can understand the publication requirements. The file https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/contributing.md is a good candidate, but it's short boilerplate.
What happened?
See the discussion here for details.
Top level request: Can we have a single document which explains the requirements for publishing a BCR entry for a module which brings in a new well-known library into the BCR?
A (longish) summary, with rationale, below.
homepageparam should point to.It would seem fair that if there's an expectation of what it should be, that it's written up in a discoverable place.
Might as well be. But if it is, it would be nice to have a document that says as much, and explains the expected workflow we're supposed to follow.
I observed that so far the approach has been governed by "case law", but is there a reason now to not write it up somewhere? If there was a BCR publication checklist, I'd be more than happy to read it and follow it.
I understand how to publicize an overlay should one decide to do so. But it's unclear to me how this is automatable. As far as I understand the current status is: you have files to overlay, you have the library source, good luck.
Instead, it would be nice to have a preferred workflow description that a would-be contributor could use.)
homepage.However, not clear to me how not pointing a link at the place where the BCR additions live help make the supply chain case. I actually have the opposite problem with BCR overlays: that the overlay additions are somewhat not front and center, even though they are just as powerful in terms what they can do to the end result as is the library source itself.
//docsseem unwieldy.Maybe not so much to a trained eye... But: it is not clear to me which of them a contributor should read so that they can understand the publication requirements. The file https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/contributing.md is a good candidate, but it's short boilerplate.