On Tue, 23 Apr 2019 at 12:50, Stephen Gallagher <sgall...@redhat.com> 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. > > > I would suggest 2. It is better to deal with hard failures versus 'Oh we have to respin F31 because well we finally found that subtle misbehavior' > So I'm asking for opinions on which route we should take. > > > [1] > https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L270 > [2] https://github.com/fedora-modularity/libmodulemd/issues/269 > [3] > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-04-23/modularity.2019-04-23-15.01.log.html > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
