On Wed, Dec 02, 2020 at 12:15:21PM -0800, Adam Williamson wrote: > with quite a lot of consequences. It has consequences, for instance, > for our most important forms of communication to the wider world: how > do we pivot from this simple story that "Fedora is a (set of) > product(s) that come(s) out every six months, look out for our big > Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO > this other thing that has three streams which release every two weeks > and roll over according to some completely other schedule"? And so on. I think some of this is helped by not thinking of Fedora as the OS itself, just like Red Hat isn't RHEL and RHEL isn't Red Hat. I mean, it doesn't solve any of your problems :) but it's a start towards getting people to think about it differently. I think this reads a lot more simply: Fedora is a project that has a set of deliverables that have traditionally been released every six months. We now have some deliverables that follow a different schedule. We're moving to a model where our main underlying software repository updates on the traditional six-month cadence, our various products will come with their own release announcements. Fedora Workstation, which is our most popular desktop offering, will stay on the familiar April/October release cadence. Silverblue, IoT, and CoreOS are examples of other Fedora operating system flavors that follow a rolling-release model instead. Our KDE Plasma Desktop follows the upstream KDE releases, which happen every four months, using the most-current Fedora software base at that time. [This last statement is obviously not true, but I'd like it to be a possiblity.] On the other hand, our Fedora School OS flavor [also not real] updates only once a year, at the end of May, so that school IT teams can deploy over the summer and not worry about upgrades until the next summer. Obviously there's some hard work to make that into a reality. But that's what I'd like to get to and it's basically what the Council decided we'd like a couple of years ago. (See below.) Right now, most of the press we get is around Fedora Workstation no matter what we do. (I have tried very hard to get press folks to talk about Fedora Server, Atomic, CoreOS, IoT, KDE and Xfce, SoaS, etc., etc., and I'm lucky if I get a line or two in an article.) If we want press around other offerings — desktop, or other use cases — it'll actually be _better_ to split them off so they're not overshadowed. > Good question! getfedora.org uses the concept, but doesn't define it. > So the authoritative source, I guess, is still > https://fedoraproject.org/wiki/Editions , which says "Fedora Editions > are curated sets of packages, guidelines and configuration, and > artifacts built from those pieces, that address a specific, targeted > use-case. The Editions are the primary Fedora outputs that most Fedora > users are encouraged to use and directed towards through the download > site." The latest official definition is in https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what_does_this_mean, which says: "Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases." I'm not super-set on that, though, and would be open to some further evolution. For example, "gating tests for our releases" should probably be "for the twice-yearly Fedora rpm repository major-version releases" or something.¹ And, I think some element of this still is the key thing: we shouldn't do the general-repo release if it's not possible for the next release of an Edition to be based on it. This document is where we also said "Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence."² > Rawhide isn't an edition, which I think should be clear from the > definitions above. Rawhide is sort of the primordial soup from which > Editions and all else eventually emerges, I guess. :P I am totally up for renaming it to Fedora Primordial Soup. :) ... 1. I'm also open to having more or fewer things that are Editions, and finding new and better ways to let teams promote their not-labeled-as-edition outputs. 2. Put "release cadence" in bold for the purposes of this message. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ 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
