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