On Tue, Apr 23, 2019 at 12:50 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > It is not mentioned anywhere in the official packager documentation, > but the modulemd format for packages includes a default[1] for the > `ref:` attribute of RPM components. Essentially, if you leave the > `ref:` out of the YAML, the Module Build Service will interpret that > as a reference to the HEAD of the `master` branch in the git > repository. > > Recently, Vit Ondruch raised a request[2] that we change this behavior > such that instead of matching `master`, it should instead reference > the HEAD of a branch of that component that matches a prefixed branch > of the module. > > So, for example, if we were building the `nodejs:10` module stream, if we had: > ``` > data: > ... > components: > nodejs: > rationale: Javascript runtime and npm package manager. > buildorder: 10 > ``` > (lacking a `ref:`) > > This would be interpreted as `ref: stream-nodejs-10` instead of `ref: > master`, as now. > > > In today's Modularity Working Group Meeting[3], those present > generally agreed that this was a better approach and lends itself to a > better packager experience. We did not, however, come to an agreement > on how to transition to this new default. > > There are two possible approaches we can take: > 1) Allow MBS to look first for the branch of the component matching > the module stream (`stream-nodejs-master`) and then fall back to > 'master'. > 2) Interrogate all of the modules in Fedora, migrate any components > missing a `ref:` explicitly to be `ref: master`, then change MBS to > treat the unset value as above. > > Arguments for 1) are that it won't break backwards-compatibility, but > on the other hand it could lead to subtle misbehavior, such as if MBS > did a shallow or otherwise incomplete `git clone` that misses the > proper branch. > > Arguments for 2) are that it lends itself to hard failures, forcing > packagers to correct their YAML documents, at the cost of some (as yet > unspecced) initial effort. > > > So I'm asking for opinions on which route we should take. Option 2. It's more painful upfront for a small (I think?) number of people, but with the learning curve around modularity I would MUCH rather go for explicit behavior everywhere we can. Too much implicit behavior that the packager doesn't know about creates confusion and surprise down the road. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
