On Tue, 23 Apr 2019 at 12:50, Stephen Gallagher <sgallagh@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-leave@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.