On Tue, Jul 12, 2022 at 11:42:58AM -0700, Brandon Kim wrote: > Hello, > > Following the instructions in > https://github.com/openbmc/docs/blob/master/meta-layer-guidelines.md#dont-use-srcrevautorev-in-a-recipe > we'd like to request "glome_git.bb > " > to be added to the autobump list if possible (or let us know if the > instruction is outdated - or if there is concern for adding a meta-google > recipe to the autobump list). It points to a public github repo under > google: https://github.com/google/glome This instruction is correct still. You should never use AUTOREV in a recipe. It makes it so that builds are not reproducible and at a minimum breaks the release process. When we make a release we'd have to make an additional commit to pin all the AUTOREVs, which we don't currently do. If you look through the entire tree, including all the Yocto meta-layers, you shouldn't see any examples of using this in a formal meta-layer(*). I don't think we should add glome to the autobump list. This list currently only contains recipes under the openbmc org. Honestly, glome shouldn't even exist in meta-google[1]. There has been some discussion about what does "well-maintained open source projects" mean, but lately we've been interpreting this guideline to mean "nothing outside the openbmc org". The expectation is that if you really are pointing at a "well-maintained open source project" you should have no trouble getting it put into meta-openembedded instead. This saves us the trouble of having any debate about what is / is not "well-maintained". My recommendation would be to move glome to a Yocto/OE meta-layer and deal with them for updates because that is what we've been suggesting for anything not in the openbmc org lately. (*) I do see one in one of _our_ meta-layers and this needs to get fixed... one of the problems of opening up machine metas to almost any company who asks with little review oversight. 1. https://github.com/openbmc/docs/blob/master/meta-layer-guidelines.md#meta-layer-recipes-should-only-point-to-well-maintained-open-source-projects -- Patrick Williams