On Tue, Aug 08, 2017 at 03:26:04PM +0200, Petr Šabata wrote: > > Hm. I agree entirely with you, but when reading this I thought of > > another possibility. I think modularity gives people the option for a > > rolling release, where we don't have to make release == "collection of > > specific module versions". If that's one of the outcomes, then > > Changes simply become "this module version is available". > I agree. Once everything is modular, distro-wide release changes > stop making sense. Instead we should be proposing changes for > modules -- announcements of streams and such. Well, for some things, like "GNOME updated to 3.24", definitely. Others might be policy changes we want applied to all modules (new compiler flags or security choices, say) — although for these progress could be shown as "list of modules which have the change active". > Fedora release could/should still be driven by a set of low level > modules, such as Platform and a few more tightly linked with it. Assuming we are successfully all-in on this, I'd like to have separation of what we mean by "release". First a release of Platform and tightly-linked modules twice a year. Second, releases of updated Editions and Spins built on top of that. The former would be largely an internal event, and the latter would be user (and press) focused. And we could do things like update Server once a year, Atomic every two weeks, Workstation twice a year, KDE three times a year (or whatever). > Would it make sense to split the compose into two or more in this > case? "Platform and stuff" + "Other, mostly independent stuff"? I'd like to see the compose split up as much as possible. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
