On Tue, Nov 27, 2018 at 10:56 PM drago01 <drago01@xxxxxxxxx> wrote: > > > > On Tuesday, November 27, 2018, Owen Taylor <otaylor@xxxxxxxxxx> wrote: >> >> On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >> > As came up in another part of the earlier thread, I think this is an >> > opportunity for Modularity. For those things like GNOME that want to >> > rev mid-release, if they shipped the 3.34 release as new stream, those >> > that want to move to it will have that option, and those who fear >> > change can remain on the 3.32 release, even if it's not getting >> > support. This would have to be something communicated at release-time >> > of course. >> >> If we want to offer optional GNOME-3.34, a module is probably a better >> alternative to using a copr - which is what we did last time. >> (https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/) But >> we have to recognize that if we create such a module we are >> effectively creating a Fedora 30.1 - because libraries in that module >> will replace system libraries. From the point where we release such a >> module, any RPM-packaged applications that use GNOME libraries will >> have to be tested against *both* F30 and F30+gnome-3-34. >> >> It's also a minimally scalable approach - we wouldn't want to have a >> GNOME 3.34 module and a NetworkManager-1.16 module and support >> arbitrary combinations. >> >> And we'd have to figure out some strategy for not breaking F31 updates >> when you have the desktop:3.34 module enabled. >> >> > > I don't think modules are useful for non self contained package sets (like a desktop environment). As you said we might end up having half the distro in that module. I'm not sure this is a bad thing. My understanding is that modules are designed to allow for this in a transparent way to to the "half" of the system that isn't in the module. I realize this can create a huge build/test matrix, but putting down some boundaries can allow us to reduce the matrix to a manageable size (with automation we need anyway) and not block someone who has a reason to need somethign different from either building their own bits to fill in parts of the matrix or possibly federating with our build system to fill in gaps for themselves and their community. regards, bex > > > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx -- Brian (bex) Exelbierd | bexelbie@xxxxxxxxxx | bex@xxxxxxxxx Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
