On lunes, 5 de diciembre de 2016 9:47:43 AM CST Matthew Miller wrote: > The stats I get are about a week behind, which means I now have > information about the first week of the Fedora 25 release. See the > graph here: > > https://mattdm.fedorapeople.org/stats/fedora-os-select-2016-11-22.png > > (and please note the caveats about what you're looking at — the numbers > on the left shouldn't be construed as "number of Fedora systems" or > anything like that). > > I'd draw it in ASCII art, but the detail is hard to reproduce. :) > > Anyway, there's great news: the F25 uptake is rapid. One week after the > release, we're at about the 40k mark, and previous releases going back > to F21 were at around 30k at that time. So, awesome work, everyone. > > I have another observation, though: we've had a clear trend since F20 > where the peak of each release is being higher than the last, but we > broke that with F24, which didn't approach F23 and even fell about 2% > short of F22's peak. > > On the graph, you can see that each release has steady growth until the > next release's beta comes out, at which point it slows down, and then > drops dramatically when that next release is out. This is even true of > the year-long F20 release. This suggests that by keeping to the shorter > schedule for F25 — which was *longer* than I wanted! — we cut off F24 > from reaching its full potential. > > So, first, putting together a release is a lot of work. If we're > stepping on the toes of the previous releases, are we wasting some of > that work? > > Second, from a press/PR point of view, I think we get less total press > from having twice-a-year releases than we would from just having one > big one. When it's so frequent, it doesn't feel like news. > > Third, the modularity initiative and the "generational core" give us an > opportunity to rethink how we are doing releases entirely. (See Stephen > Gallagher's blog post if you need a quick overview of this: > https://communityblog.fedoraproject.org/base-runtime-generational-core/) > > What if, instead of two releases a year, we updated the Generational > Core on a cycle aligned with the kernel — roughly every three months — > and had one June release of Fedora Workstation and Fedora Server every > year, with an optional ".1" update in November or December? Fedora > Atomic would keep to two-week updates as a rolling release. And Spins > could pick their own release dates, either with the Editions release or > separately (to get their own chance to shine). We currently do not have the release engineering resources to do everything seperatly, we would also need to spend significant time retooling how we build everything, for instance today we ignore sources for the spins, if we ship things on different cadences we would need to make installers per spin that included the binaries and sources that go into each one. we would also need to figure out how to tag each release, and we would no longer have one things that is say f27. It would come with a bigger cost for mirrors. As we make more of the release process automated and hands off some of it will become possible. but we are still a pretty significant way off being able to do some of this. There is a lot of pieces here that I suspect have not been considered because they are in the back of house and most people do not ever think of them. we would need to reconsider how upgrades work, or if we ship things as a rolling release. a big concern I have with any of it is making sure that we publish the matching sources for each binary deliverable. > That's just an idea — I'd love to hear your thoughts. Properties I'd > like to have in any plan are: > > * predictable calendar dates, to help with long-term planning > * not being on a hamster wheel which routinely bursts into flame > * maintaining the high level of QA we have for releases (or, you know, > even increasing it) > * doesn't increase work for packagers > * including time for QA and Rel-Eng to a) breathe and b) invest in > infrastructure > * satisfying upstream projects which depend on us as an early delivery > mechanism to users (GNOME, GCC, glibc, have spoken up before, but not > limited to just those) Not sure any plan really will suit any/all of the upstream projects. > * maximum PR and user growth > > ...and there are probably other important factors you can think of that > I haven't. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
