On Tue, 2019-11-05 at 17:55 -0500, Randy Barlow wrote: > To avoid the word "slot", what I'm saying is why not just add a > "Stream" field to the RPM spec file (so, instead of NEVR, it's NESVR), > and provide a way for users to specify which streams they want to > follow? So, a couple of thoughts on this. There's a constraint we have that Gentoo doesn't here: releases. Gentoo doesn't have releases. So, we have to consider how this stream system would interact with releases. This has a few consequences I can think of. For a start it means the actual problem we're currently having with our current module streams wouldn't necessarily be solved by your system - we could've run into exactly the same problem, more or less; the libgit2 package could've declared a '0.27' stream in F29 and then decided that in F31 it wanted everyone on the '0.28' stream, or something like that. We still have the potential problem of needing to define rules and implement mechanisms for stream transitions at release boundaries, essentially. Another one - how does this work on the packaging end? Do I have some sort of combinatorial explosion of dist-git branches for "release+stream", so that if I introduce a stream called 'foo' I get an f29-foo git branch, an f30-foo git branch, an f31-foo git branch and a master-foo git branch? Then I get another four branches for each new stream? And each time a release comes out I get X new branches, where X is the amount of streams that exist? Or would there be another way to do it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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