On Tue, Mar 17, 2020 at 7:32 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > The trigger for this line of thinking was this comment I ran across > this morning: > > https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1166100-fedora-32-beta-released-with-earlyoom-by-default-gnome-3-36-desktop?p=1166101#post1166101 > > Put yourself in that person's shoes - just a regular community > enthusiast who's interested in Fedora. They're reading the news sites > (doesn't have to be Phoronix, could be anywhere). They see a story that > Fedora 32 Beta is out. As you can see from that comment, we've done > enough public communication about them that this person is aware that > 'Silverblue' and 'CoreOS' are Fedora Things that are kind of important. > That's why they're expecting them to be a part of a Fedora 32 Beta > release announcement. But, what do they find? Nothing! The announcement > doesn't mention them, the download page doesn't mention them, nothing > in the story we're telling around the Beta references them at all. It > means we're not telling people a coherent story about what Fedora is > and where it's going. That in turn will damage their confidence in > 'Fedora' as a whole, even if they try a bit of the beta that *is* there > and find it works great. It's still going to be in their head that we > don't seem to have our story as to where we're going completely > straightened out. That's not a problem of the IoT team or the CoreOS > team or the Silverblue team, it's a *Fedora* problem, which is why it > needs a 'Fedora' body or person to care about it. I don't think it'd be acceptable to consider those variants as important if they can't be aligned to our development milestones. In general, I *expect* that *every* deliverable that comes from the Fedora Linux collection of software should be present and marketed at each development milestone, *including* the final release. It's either that or allow *all* variants of desynchronize, and I think that's probably not a good idea. Desynchronizing the lifecycle of all the variants makes life much more difficult for users, developers, and testers (basically everyone!) because it becomes far less predictable to figure out what "makes up" a Fedora release. I know that Fedora CoreOS and IoT Edition want to try to de-emphasize the Fedora release they're based on (be more rolling and whatnot), but I'm not sure that's a good idea for marketing/visibility and contribution cognition reasons. As it stands, I have a hard time figuring out what's going on with both of these variants because they don't make it obvious what they're working from, what their plans are, and where they're going. That said, I think it's fine for these variants to "end" earlier and have users seamlessly switch to the next release. The way those variants work mean that this is (hopefully) less painful to do. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
