Re: Modularity component ref: behavior
Ping. Any update here? Vít Dne 23. 04. 19 v 18:14 Stephen Gallagher napsal(a): > 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. > > > [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
Re: Modularity component ref: behavior
Dne 23. 04. 19 v 18:14 Stephen Gallagher napsal(a): > 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. And I also proposed fallback to master when no matching branch is found. > > > 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. When I was thinking about the migration, it always felt natural to me to bump the module metadata version and treat the ref differently by the version. Vít > > 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. > > > [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
Re: Modularity component ref: behavior
On Tue, Apr 23, 2019 at 2:52 PM Ben Cotton wrote: > > Could we take both routes? That is go with the first option for some > defined period to give maintainers time to add the desired `ref:` and > then at some point say "okay, now we're doing it the hard way". That > seems like the most packager-friendly approach, assuming it's > reasonably feasible. That's not both. That's option 2. The only discussion point would then be the timeframe. I would suggest the timeframe be: "as long as it takes to implement the change in MBS, get it tested, and get it deployed into production". :) josh ___ 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
Re: Modularity component ref: behavior
Could we take both routes? That is go with the first option for some defined period to give maintainers time to add the desired `ref:` and then at some point say "okay, now we're doing it the hard way". That seems like the most packager-friendly approach, assuming it's reasonably feasible. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ 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
Re: Modularity component ref: behavior
On Tue, Apr 23, 2019 at 12:50 PM Stephen Gallagher 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@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
Re: Modularity component ref: behavior
On Tue, 23 Apr 2019 at 12:50, Stephen Gallagher 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
Modularity component ref: behavior
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. [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
