As general feedback, the footnotes make it hard to read the rendered version of 
the document, forcing  me to scroll up and down.

More comments below.

On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> * If a stream of a module has build-time-only components, all such
> components *MUST* be marked as `buildonly: True` in the module
> metadata to avoid shipping them to users and polluting their
> repository.
> 

Can these be directed to a disabled-by-default build-dep repo of some kind for 
those trying to do local builds?

Do these "non-shipped" packages shadow non-modular versions of the same 
packages?

> == Requirements for Default Streams

I'd propose an alternative to Default Streams. Any package part of a default 
stream should instead be auto-built in a given release where the stream is 
marked as default. Pushes to the dist-git branch for that release would be 
blocked by all but the auto build bot, and all changes should be made to the 
stream branch.

The stream marked "default" for the particular module would be enabled as a 
buildroot override, including build only packages, for such automated 
non-modular rebuilds of streams marked "default".  This would obviate the need 
of stream transition, except in cases if inter-module deps.

Even given the status quo, I'd argue that streams enabled by nature of being 
Default rather than being explicitly enabled, should not shadow non-modular 
packages. As-is today, third party repos are marking themselves as 
module_hotfixes to skip the shadowing issues.

> * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> permits defaults streams that adhere to the policy below.

Say EPEL, don't mention version.

> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as an RPM in a default stream in the same release except

"default stream of another module"

> in the case of a transition from one to the other.footnote:[In this
> situation, whichever has the highest NEVRA would win the depsolving
> and could break the other module.]

V/r,
James Cassell
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to