Is this just about the specific URL or also about the "Naming Policy"? I am asking, because I already had a lot of arguments about the branching on this list and various different places but this guideline still insist that "using upstream major versions as branches is recommended". This is not acceptable, because this works just for simplest cases, such as there is module "nodejs" shipping single package "nodejs". It does not work for even slightly more complex cases when module "nodejs" includes not just "nodejs" package, but also lets say "npm" package. Having Node.js versioned brachnes in "npm" is wrong. Not mentioning that if I'll have "mynodejs" module, using both "nodejs" and "npm" and probably also other packages, the versions will be already occupied by "nodejs" module. IOW, the modular packages must live in "module-version" branches by default. This avoids conflicts and provides more understanding why "npm" package has some branches. Vít Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/ModularPolicy > > == Summary == > Establish a set of rules for Modular content in Fedora to ensure an > optimal user and packager experience. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgallagh@xxxxxxxxxx > > == Detailed Description == > Over the last several months, members of the Modularity WG and FESCo > have been working to establish a policy for module inclusion in > Fedora. We now have a proposal that FESCo requested be taken to the > Fedora community via the Change Proposal. > > There is a preview of the new policy available at > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > == Benefit to Fedora == > This policy makes explicit what packagers can and cannot do with > Modules in Fedora, which should avoid future issues like those that > were seen during the Fedora 31 and Fedora 32 cycles. > > == Scope == > * Proposal owners: > The proposal is written, so minimal work remains. We may need to make > revisions or clarifications based on public feedback. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > N/A this is not a user-facing change. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
