On Mon, Sep 24, 2018 at 7:04 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
I thought about this for a while, and I can see some conceptual similarities between upgrading a major Fedora release and changing a module stream. I tried to think about major Fedora releases (I mean f28, f29, etc) as "streams" of Fedora, the same way as streams of modules, with stable API.Until now, there was a single type of upgrade in Fedora — the major release upgrade. But with Modularity, there is more than that. It's no longer single monolithic upgrade of the whole OS. People can now upgrade (== change streams) different parts of the OS potentially independently. We need to think how to present this to users. Will it require a change of mindset?
I think we have to be very careful about making the default experience have too much complexity to it. For graphical applications we are using Flatpaks to get this separation of OS upgrade and application upgrade, *but* we're planning to have applications be single stream - so applications just roll forward with upstream stable releases. So the total complexity stays low.
Also, with the effort of separating apps and the OS we've discussed at Flock, will the goal be to get the "OS part" upgradable at any time, and, independently on that, users will choose to upgrade (again, change streams) individual parts of the system (modules) for new features? That probably will require a change of mindset. It sounds similar how a phone works. Do we need to develop a whole new UX around this?
We have no current plans to create a *graphical* user experience around installation of modules as loose packages. Even creating a decent command line experience around it seems very difficult, since if you allow independent module maintenance, two modules can start conflicting at any time (even without a branch switch!).
"Updated versions of reviewboard and sagemath have different versions of python2-<something>, do you want to"
A) Remove reviewboard
B) Remove sagemath
C) Use the version of python2-<something> from reviewboard and hope for the best
D) Use the version of python2-<something> from sagemath and hope for the best
E) Find a nearby brick wall to bang your head against
On the other hand, if you don't allow independent module maintenance and enforce compatible versions across the entire set of modules included in the modular compose, you've lost some of the point of modularity... still, that's better, in my opinion than presenting the user with lose-lose options.
Owen
On Thu, Sep 20, 2018 at 11:01 PM Randy Barlow <bowlofeggs@xxxxxxxxxxxxxxxxx> wrote:On 9/20/18 1:56 PM, Matthew Miller wrote:
> If it's "they'll find out when dnf system-upgrade errors out!", then see
> above. I'm ... not enthused. Something in dnf system-upgrade needs to do it;
> possibly a "dnf system-upgrade prep" step before "download".
I agree. Would it be feasible for the system-upgrade plugin to prompt
the user with "hey, you are using 1.7 but you need to switch to 1.8 to
upgrade. Proceed? (y/N)".
_______________________________________________
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
--_______________________________________________Software Engineer
Adam Šamalík
---------------------------
Red Hat
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
_______________________________________________ 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
