On Thu, Oct 17, 2019 at 9:39 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Wed, Oct 16, 2019 at 03:03:02PM -0400, Stephen Gallagher wrote: > > On Wed, Oct 16, 2019 at 2:56 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Oct 16, 2019 at 01:32:49PM -0400, Stephen Gallagher wrote: > > > > remove it" or something like that. It should never be used in the > > > > general case. Not even for "This is so old we should force upgrades". > > > > For that we should just drop the stream entirely from the next > > > > release, which would result in the upgrade being impossible until the > > > > user took a manual action to get off that stream. > > > > > > What might that look like from a UX perspective? What about from GNOME > > > Software? > > > > Given that this should *almost never* happen, I'd avoid going to great > > lengths to build UX around it. I think it should basically just > > *happen* as part of the update process. I want to repeat: this should > > only be used if we have absolutely no other choice. I'd say the most > > UX we should do is actually in CI: we should disallow a module update > > to be pushed with this attribute set without an override. > > I think Matthew's question was not around the Obsolete: tag but when we drop the > stream of a release. > Say I've enabled django1.6 and it has gone EOL upstream so you've dropped it in > F32, what will happen when I try to upgrade to F32 using GNOME Software? Or, even better (or worse): Sombody installs GIMP via GNOME Software, and under the hood, dnf does its magic and installs gimp from the module, which might depend on another, even non-default module, etc. But then, what will happen when that module is EOL, and the user has never even interacted with dnf, or modules? Will system upgrades break and prompt the user to fix something they didn't even know existed, and have never interacted with? Fabio > Pierre > _______________________________________________ > 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 _______________________________________________ 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
