Some preliminary Fedora 25 stats — and future release scheduling

[Matthew Miller]

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).

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)
* maximum PR and user growth

...and there are probably other important factors you can think of that
I haven't.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Gerald B. Cox]

On Mon, Dec 5, 2016 at 6:47 AM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  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?
>  
I don't see the relevance of that observation.  A new version, whenever it
is released
will impact the uptake of the previous.  If you're saying you believe two
releases a year
is too much work and unsustainable - if true, then there are probably
metrics to support
that concern.


>  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.
>  
Basing our release strategy on the fickleness of press coverage is
subjective and isn't going to do give any consistent results.

>  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/)
>  
Kevin's comment raised some important concerns about this.

[Matthew Miller]

On Mon, Dec 05, 2016 at 09:04:11AM -0800, Gerald B. Cox wrote:

>  > 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?
>  I don't see the relevance of that observation.  A new version,
>  whenever it is released will impact the uptake of the previous. If 
I'm saying in this case, we released it before the previous version had
a chance to make as much impact as it could have.


>  > 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.
>  Basing our release strategy on the fickleness of press coverage is
>  subjective and isn't going to do give any consistent results. 
But I didn't say this was due to fickleness. In any case, a release is
*definitely* a marketing event as well as a technical one, and PR is a
legitimate input into planning them.



>  > Third, the modularity initiative and the "generational
> core" give
>  > us an opportunity to rethink how we are doing releases entirely.
>  Kevin's comment raised some important concerns about this. 
I don't want to misrepresent Kevin's concerns, but as I understand
them, they're with modularity in conception rather than to do with
scheduling. I guess there's an intersection in that if we can't do
modularity at all it makes the particular release cycle I suggested
much harder to do — but overall I think it's a separate conversation.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Gerald B. Cox]

On Mon, Dec 5, 2016 at 11:53 AM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  > > 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?
>  > I don't see the relevance of that observation.  A new version,
>  > whenever it is released will impact the uptake of the previous. If
>
>  I'm saying in this case, we released it before the previous version had
>  a chance to make as much impact as it could have.
>  
Thanks for the response.

If you're saying that you believe 5 months
wasn't long enough - I suppose that is fair... but the reason there was
only 5 months wasn't by
design - it was due to schedule slippage.  As far as impact - I still not
sure what that means?
Software is constantly being updated, evolving.  How does running older
versions of software
increase "impact"?

I don't believe we are "wasting" work.  Regardless of their lifespan, all
releases are appreciated and
valued.  They don't have to "age" like a wine.  If you're trying to say
resources are limited and the
current release schedule has become unsustainable - that is another issue
entirely.

>  > > 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.
>  > Basing our release strategy on the fickleness of press coverage is
>  > subjective and isn't going to do give any consistent results.
>
>  But I didn't say this was due to fickleness. In any case, a release is
>  *definitely* a marketing event as well as a technical one, and PR is a
>  legitimate input into planning them.
>  
I didn't say you said "fickleness".  That is my own opinion of the state of
our media.  I was trying
to say that you can't rely on media coverage.  Yes I understand a new
release is also a marketing
event.  I just don't believe the theoretical attention span of the media
should impact our decisions.

[Matthew Miller]

On Mon, Dec 05, 2016 at 12:41:18PM -0800, Gerald B. Cox wrote:
>  If you're saying that you believe 5 months wasn't long enough
> - I
>  suppose that is fair... but the reason there was only 5 months wasn't
>  by design - it was due to schedule slippage. As far as impact - I 
It was by design, though — for a while, when a schedule slipped, we
planned the next schedule as 6 or 7 months from the actual release.
This time, we tried to keep it to October even though the previous
release had slipped, resulting in the short schedule. I'm the person
who pushed for that (because of the value of calendar consistency), and
I'm now saying it was a mistake.


>  still not sure what that means? Software is constantly being
> updated,
>  evolving. How does running older versions of software increase
>  "impact"? 
I'm not saying running older versions increases it -- I'm saying I
don't think new versions at the rate we're putting them out are
necessary to get it.

>  I don't believe we are "wasting" work.  Regardless of
> their lifespan,
>  all releases are appreciated and valued. They don't have to "age"
>  like a wine. If you're trying to say resources are limited and the
>  current release schedule has become unsustainable - that is another
>  issue entirely. 
Right, that's another issue.


>  I didn't say you said "fickleness".  That is my own
> opinion of the
>  state of our media. I was trying to say that you can't rely on media
>  coverage. Yes I understand a new release is also a marketing event. I
>  just don't believe the theoretical attention span of the media should
>  impact our decisions. 
Okay. I have a different opinion. :)


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Gerald B. Cox]

On Mon, Dec 5, 2016 at 1:10 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  > still not sure what that means? Software is constantly being updated,
>  > evolving. How does running older versions of software increase
>  > "impact"?
>
>  I'm not saying running older versions increases it -- I'm saying I
>  don't think new versions at the rate we're putting them out are
>  necessary to get it.
>  
>  > I don't believe we are "wasting" work.  Regardless
> of their lifespan,
>  > all releases are appreciated and valued. They don't have to "age"
>  > like a wine. If you're trying to say resources are limited and the
>  > current release schedule has become unsustainable - that is another
>  > issue entirely.
>
>  Right, that's another issue. 

By other issue I meant that if that was the actually driver behind what you
are
asking, that made sense to me.  "Impact" and  "press coverage" are
very subjective criteria on which to base a decision.

[Michael Catanzaro]

On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote:
>  It was by design, though — for a while, when a schedule slipped, we
>  planned the next schedule as 6 or 7 months from the actual release.
>  This time, we tried to keep it to October even though the previous
>  release had slipped, resulting in the short schedule. I'm the person
>  who pushed for that (because of the value of calendar consistency),
>  and
>  I'm now saying it was a mistake. 
I still think it's a good idea for Workstation. We really need to be
seen as the leading GNOME distro: that's what gets GNOME people using
Workstation and recommending that other people install it, then those
people recommend it... I think it's part of the story behind our recent
rise in popularity. Right now we are that leading GNOME distro because
we usually follow about 1-2 months behind a GNOME release. It's a huge
advantage over, say, Ubuntu, where people complain about needing PPAs
to get the latest software and upstream has already moved on to newer
versions half a year ago. Right now this is one of our biggest
strengths as a distro, and your proposal would throw that away. So
there is real serious risk of changing this.

Also, if we do one release per year, then I expect most of the Red Hat
developers who work on GNOME would start using some unstable copr to
get the latest GNOME; this means way fewer developers using and testing
the latest release, since it's too stale. (I dunno what I'd do myself,
stick around and use a GNOME copr, or try to go improve Tumbleweed...?)

I'm even concerned by schedule slippage into June; this is the time of
year that I see complaints that Fedora is too old, go install Arch. I'd
prefer that we always target early May and November releases for
Workstation. I know, the early May is hard for GCC, but GCC isn't our
user experience and I'm sure it can wait until the fall releases.

A tangential argument is this will hurt our reputation for being a
leading-edge distro. Ubuntu would have newer software than us for half
the year....

Michael

[Matthew Miller]

On Mon, Dec 05, 2016 at 06:03:32PM -0600, Michael Catanzaro wrote:
>  I still think it's a good idea for Workstation. We really need to
> be
>  seen as the leading GNOME distro: that's what gets GNOME people using
>  Workstation and recommending that other people install it, then those
>  people recommend it... I think it's part of the story behind our recent
>  rise in popularity. Right now we are that leading GNOME distro because
>  we usually follow about 1-2 months behind a GNOME release. It's a huge
>  advantage over, say, Ubuntu, where people complain about needing PPAs
>  to get the latest software and upstream has already moved on to newer
>  versions half a year ago. Right now this is one of our biggest
>  strengths as a distro, and your proposal would throw that away. So
>  there is real serious risk of changing this. 
That's exactly why I'm suggesting the point release or batched update —
that would include a GNOME bump.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Michael Catanzaro]

On Mon, 2016-12-05 at 19:12 -0500, Matthew Miller wrote:
>  That's exactly why I'm suggesting the point release or
> batched update
>  —
>  that would include a GNOME bump. 
OK then, if we're willing to bump all of GNOME in a point release
(that's a lot of stuff!) then I don't object.

[Chris Murphy]

On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote:
> > It was by design, though — for a while, when a schedule slipped, we
> > planned the next schedule as 6 or 7 months from the actual release.
> > This time, we tried to keep it to October even though the previous
> > release had slipped, resulting in the short schedule. I'm the person
> > who pushed for that (because of the value of calendar consistency),
> > and
> > I'm now saying it was a mistake.
>
>  I still think it's a good idea for Workstation. We really need to be
>  seen as the leading GNOME distro: that's what gets GNOME people using
>  Workstation and recommending that other people install it, then those
>  people recommend it... I think it's part of the story behind our recent
>  rise in popularity. Right now we are that leading GNOME distro because
>  we usually follow about 1-2 months behind a GNOME release. It's a huge
>  advantage over, say, Ubuntu, where people complain about needing PPAs
>  to get the latest software and upstream has already moved on to newer
>  versions half a year ago. Right now this is one of our biggest
>  strengths as a distro, and your proposal would throw that away. So
>  there is real serious risk of changing this.
>
>  Also, if we do one release per year, then I expect most of the Red Hat
>  developers who work on GNOME would start using some unstable copr to
>  get the latest GNOME; this means way fewer developers using and testing
>  the latest release, since it's too stale. (I dunno what I'd do myself,
>  stick around and use a GNOME copr, or try to go improve Tumbleweed...?) 
I'd expect .1 or +1 would rebase on the most recent GNOME.


>  I'm even concerned by schedule slippage into June; this is the
> time of
>  year that I see complaints that Fedora is too old, go install Arch. I'd
>  prefer that we always target early May and November releases for
>  Workstation. I know, the early May is hard for GCC, but GCC isn't our
>  user experience and I'm sure it can wait until the fall releases. 
May is also good in that it's not yet "summer time".


-- 
Chris Murphy

[Daniel P. Berrange]

On Mon, Dec 05, 2016 at 06:41:27PM -0700, Chris Murphy wrote:
>  On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt; wrote:
>  > On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote:
>  >> It was by design, though — for a while, when a schedule slipped, we
>  >> planned the next schedule as 6 or 7 months from the actual release.
>  >> This time, we tried to keep it to October even though the previous
>  >> release had slipped, resulting in the short schedule. I'm the person
>  >> who pushed for that (because of the value of calendar consistency),
>  >> and
>  >> I'm now saying it was a mistake.
>  >
>  > I still think it's a good idea for Workstation. We really need to be
>  > seen as the leading GNOME distro: that's what gets GNOME people using
>  > Workstation and recommending that other people install it, then those
>  > people recommend it... I think it's part of the story behind our recent
>  > rise in popularity. Right now we are that leading GNOME distro because
>  > we usually follow about 1-2 months behind a GNOME release. It's a huge
>  > advantage over, say, Ubuntu, where people complain about needing PPAs
>  > to get the latest software and upstream has already moved on to newer
>  > versions half a year ago. Right now this is one of our biggest
>  > strengths as a distro, and your proposal would throw that away. So
>  > there is real serious risk of changing this.
>  >
>  > Also, if we do one release per year, then I expect most of the Red Hat
>  > developers who work on GNOME would start using some unstable copr to
>  > get the latest GNOME; this means way fewer developers using and testing
>  > the latest release, since it's too stale. (I dunno what I'd do myself,
>  > stick around and use a GNOME copr, or try to go improve Tumbleweed...?)
>  
>  I'd expect .1 or +1 would rebase on the most recent GNOME. 
I expect we'd also rebase the virtualization stack in any .1 release,
or even in the middle of a release if Fedora switched to a yearly
major release cycle. 6+ months is already a long time to wait to push
out new features to users, so making it longer is really not helpful
from KVM virt stack pov.

If we get lots of stuff rebasing in a .1 release though, it seems that
the result is not dramatically different from what we're doing today
with 6 monthly releases. 


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

[Matthew Miller]

On Tue, Dec 06, 2016 at 09:11:06AM +0000, Daniel P. Berrange wrote:
>  I expect we'd also rebase the virtualization stack in any .1
> release,
>  or even in the middle of a release if Fedora switched to a yearly
>  major release cycle. 6+ months is already a long time to wait to push
>  out new features to users, so making it longer is really not helpful
>  from KVM virt stack pov. 
Would these updates just add new features or -- not counting accidental
regressions -- do they sometimes remove or change existing
functionality significantly? Would it be possible to reserve the latter
for the full release?




-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Daniel P. Berrange]

On Tue, Dec 06, 2016 at 03:13:51PM -0500, Matthew Miller wrote:
>  On Tue, Dec 06, 2016 at 09:11:06AM +0000, Daniel P. Berrange wrote:
>  > I expect we'd also rebase the virtualization stack in any .1 release,
>  > or even in the middle of a release if Fedora switched to a yearly
>  > major release cycle. 6+ months is already a long time to wait to push
>  > out new features to users, so making it longer is really not helpful
>  > from KVM virt stack pov.
>  
>  Would these updates just add new features or -- not counting accidental
>  regressions -- do they sometimes remove or change existing
>  functionality significantly? Would it be possible to reserve the latter
>  for the full release? 
As a general rule they'd always be adding new features. The only things
that get removed as stuff users are not likely to hit (eg support for
QEMU machine types that are 5+ years old which no one will seriously be
running anymore)

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

[Gerald Henriksen]

On Tue, 6 Dec 2016 09:11:06 +0000, you wrote:

> > I'd expect .1 or +1 would rebase on the most recent GNOME.
>
> I expect we'd also rebase the virtualization stack in any .1 release,
> or even in the middle of a release if Fedora switched to a yearly
> major release cycle. 6+ months is already a long time to wait to push
> out new features to users, so making it longer is really not helpful
> from KVM virt stack pov. 
The world has changed quite a bit since Fedora was launched, and as
anyone running stuff in the non-Linux world has experienced:

1) the base OS is on a yearly cycle with minor updates between (not
just macOS and Windows 10, but iOS and Android as well).

2) many of the apps one now uses update automatically without user
intervention so you never know what version of Firefox/Chrome/etc you
are using - users have gotten used to if not actually expecting that
the software continously updates and no user attention is requied
unless it is a significat change.

> If we get lots of stuff rebasing in a .1 release though, it seems
> that
> the result is not dramatically different from what we're doing today
> with 6 monthly releases.  
So you restrict a .1 release to anything critical to the running of
the OS, and let the apps upgrade as they want.  This can have a couple
of influences on testing:

a) you only make 1 release a year installable, everything else is an
in place downloaded update via dnf.   Side-effect, this helps the
issue brought up elsewhere on the list about testing of physical
install discs.

b) presumably it is easier for testing to test individual apps with
major changes throughout the yearly release as opposed to cramming
everything into a short period before each 6 month release.

c) if the move to updates during a release is allowed, then it can
perhaps remove the haste in getting some applications "out the door"
in time for a Fedora alpha release, allowing more developer testing
prior to being thrown on top of Fedora (and perhaps then making it
easier to actually get Fedora released on time).

d) while there will still be some components that need to wait for an
official Fedora release - big compiler changes, incompatible
libraries, databases (maybe depending), it should hopefully reduce the
pressure to get everything into a release and thus ease the burden on
testing.

[Adam Williamson]

On Tue, 2016-12-06 at 16:47 -0500, Gerald Henriksen wrote:
>  So you restrict a .1 release to anything critical to the running of
>  the OS, and let the apps upgrade as they want. 
You say that like it's something trivial, rather than something we've
spent (by my count) about 4 years trying to define / implement so
far...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Peter Robinson]

On Tue, Dec 6, 2016 at 9:11 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote:
>  On Mon, Dec 05, 2016 at 06:41:27PM -0700, Chris Murphy wrote:
> > On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
> wrote:
> > > On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote:
> > >> It was by design, though — for a while, when a schedule slipped, we
> > >> planned the next schedule as 6 or 7 months from the actual release.
> > >> This time, we tried to keep it to October even though the previous
> > >> release had slipped, resulting in the short schedule. I'm the person
> > >> who pushed for that (because of the value of calendar consistency),
> > >> and
> > >> I'm now saying it was a mistake.
> > >
> > > I still think it's a good idea for Workstation. We really need to be
> > > seen as the leading GNOME distro: that's what gets GNOME people using
> > > Workstation and recommending that other people install it, then those
> > > people recommend it... I think it's part of the story behind our recent
> > > rise in popularity. Right now we are that leading GNOME distro because
> > > we usually follow about 1-2 months behind a GNOME release. It's a huge
> > > advantage over, say, Ubuntu, where people complain about needing PPAs
> > > to get the latest software and upstream has already moved on to newer
> > > versions half a year ago. Right now this is one of our biggest
> > > strengths as a distro, and your proposal would throw that away. So
> > > there is real serious risk of changing this.
> > >
> > > Also, if we do one release per year, then I expect most of the Red Hat
> > > developers who work on GNOME would start using some unstable copr to
> > > get the latest GNOME; this means way fewer developers using and testing
> > > the latest release, since it's too stale. (I dunno what I'd do myself,
> > > stick around and use a GNOME copr, or try to go improve Tumbleweed...?)
> >
> > I'd expect .1 or +1 would rebase on the most recent GNOME.
>
>  I expect we'd also rebase the virtualization stack in any .1 release,
>  or even in the middle of a release if Fedora switched to a yearly
>  major release cycle. 6+ months is already a long time to wait to push
>  out new features to users, so making it longer is really not helpful
>  from KVM virt stack pov.
>
>  If we get lots of stuff rebasing in a .1 release though, it seems that
>  the result is not dramatically different from what we're doing today
>  with 6 monthly releases. 
Completely agree here, there's also the same risk of instability
without the advantage of being able to add features that require
toolchain/mass rebuild changes.

Peter

[Chris Murphy]

On Mon, Dec 5, 2016 at 12:53 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 09:04:11AM -0800, Gerald B. Cox wrote:
>
> > > 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?
> > I don't see the relevance of that observation.  A new version,
> > whenever it is released will impact the uptake of the previous. If
>
>  I'm saying in this case, we released it before the previous version had
>  a chance to make as much impact as it could have.
>
>
> > > 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.
> > Basing our release strategy on the fickleness of press coverage is
> > subjective and isn't going to do give any consistent results.
>
>  But I didn't say this was due to fickleness. In any case, a release is
>  *definitely* a marketing event as well as a technical one, and PR is a
>  legitimate input into planning them.
>
>
>
> > > Third, the modularity initiative and the "generational core" give
> > > us an opportunity to rethink how we are doing releases entirely.
> > Kevin's comment raised some important concerns about this.
>
>  I don't want to misrepresent Kevin's concerns, but as I understand
>  them, they're with modularity in conception rather than to do with
>  scheduling. I guess there's an intersection in that if we can't do
>  modularity at all it makes the particular release cycle I suggested
>  much harder to do — but overall I think it's a separate conversation. 
I'm not sure it's much harder to do without modularity. Right now
Fedora could do a Fedora 26 release without any conventional release
media for server and workstation, by just using dnf system-upgrade and
gnome-software. And in a sense that's more like how the incremental
release for rpm-ostree based installations end up working out anyway.

Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
with relaxed rules about what sorts of things can be significantly
updated? A huge part of the effort for each release is sun baking the
rawhide. And what effect does a once a year major release have on
Rawhide? Or what effect do we want it to have?




-- 
Chris Murphy

[Matthew Miller]

On Mon, Dec 05, 2016 at 01:43:58PM -0700, Chris Murphy wrote:
>  I'm not sure it's much harder to do without modularity. Right
> now
>  Fedora could do a Fedora 26 release without any conventional release
>  media for server and workstation, by just using dnf system-upgrade and
>  gnome-software. And in a sense that's more like how the incremental
>  release for rpm-ostree based installations end up working out anyway. 
True.

>  Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
>  with relaxed rules about what sorts of things can be significantly
>  updated? A huge part of the effort for each release is sun baking the
>  rawhide. And what effect does a once a year major release have on
>  Rawhide? Or what effect do we want it to have? 
I was thinking a branch off of 26 with relaxed rules. I'm not sure what
the EOL policy would be like — could be any of

* treat both .0 and .1 releases as we do full releases now (which would
  make each release go EOL a month after the *next* .0 or .1)
* end the .1 release support at the same time .0 ends
* make the .1 point a big update bundle and not support .0 after that,
  but taking the whole thing around to after the next .1

Rawhide is a good question. I'd like to see the more-stable-rawhide
("Bikeshed!") idea in place, and hopefully more people running that,
making it more likely that Rawhide is at a good place for stabilization
when we branch for the annual release.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Chris Murphy]

On Mon, Dec 5, 2016 at 2:26 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 01:43:58PM -0700, Chris Murphy wrote:
> > I'm not sure it's much harder to do without modularity. Right now
> > Fedora could do a Fedora 26 release without any conventional release
> > media for server and workstation, by just using dnf system-upgrade and
> > gnome-software. And in a sense that's more like how the incremental
> > release for rpm-ostree based installations end up working out anyway.
>
>  True.
>
> > Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
> > with relaxed rules about what sorts of things can be significantly
> > updated? A huge part of the effort for each release is sun baking the
> > rawhide. And what effect does a once a year major release have on
> > Rawhide? Or what effect do we want it to have?
>
>  I was thinking a branch off of 26 with relaxed rules. I'm not sure what
>  the EOL policy would be like — could be any of
>
>  * treat both .0 and .1 releases as we do full releases now (which would
>    make each release go EOL a month after the *next* .0 or .1)
>  * end the .1 release support at the same time .0 ends
>  * make the .1 point a big update bundle and not support .0 after that,
>    but taking the whole thing around to after the next .1 
My inclination is that .0 should be a no new features, only the
important bug and security fixes the package maintainers want to push.
Maybe that's not much different than where Fedora 23 is right now.
Although I sorta see an advantage of making .0 EOL about a month after
.1 comes out to get more people on .1 and then let that one stick
around a while longer after the next .0 comes out. So:

Fedora 26.0   June 2017 release   EOL Dec 2017
Fedora 26.1   Nov 2017 release   EOL Dec 2018
Fedora 27.0  June 2018 release  EOL Dec 2018
Fedora 27.1  Nov 2018 release  EOL Dec 2019

This results in an 18 month over all month cycle for the visible big
number, more stability ostensibly as well. Without changing anything
else, it'd be possible to work in a .2 release, such that it's ~7
months for each, with just a month of overlap, making it still 18
months for the big version number while still pushing some new
features.

But, I think it's also workable to keep it all to a 13 month cycle,
and EOL .0 and .1 ~7 months from release.


>  Rawhide is a good question. I'd like to see the
> more-stable-rawhide
>  ("Bikeshed!") idea in place, and hopefully more people running that,
>  making it more likely that Rawhide is at a good place for stabilization
>  when we branch for the annual release. 
To me the connotation of Bikeshed has less certainty than Rawhide, so
I'd see Bikeshed > Rawhide > major release > minor release. But
whichever order, I wonder if for sure another thing is really needed
or if the stability problems with Rawhide could be better managed with
two different ostrees: nightly vs weekly, where a semi-sane nightly
can graduate to a weekly. Or oozing vs chewy. But maybe the ostree
stuff needs more sun time itself before Rawhide could be totally
flipped over to it.



-- 
Chris Murphy

[Josh Boyer]

On Mon, Dec 5, 2016 at 4:26 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 01:43:58PM -0700, Chris Murphy wrote:
> > I'm not sure it's much harder to do without modularity. Right now
> > Fedora could do a Fedora 26 release without any conventional release
> > media for server and workstation, by just using dnf system-upgrade and
> > gnome-software. And in a sense that's more like how the incremental
> > release for rpm-ostree based installations end up working out anyway.
>
>  True.
>
> > Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
> > with relaxed rules about what sorts of things can be significantly
> > updated? A huge part of the effort for each release is sun baking the
> > rawhide. And what effect does a once a year major release have on
> > Rawhide? Or what effect do we want it to have?
>
>  I was thinking a branch off of 26 with relaxed rules. I'm not sure what
>  the EOL policy would be like — could be any of
>
>  * treat both .0 and .1 releases as we do full releases now (which would
>    make each release go EOL a month after the *next* .0 or .1) 
I don't see how this is different from today other than naming.

>  * end the .1 release support at the same time .0 ends 
That would seem to break common expectation that point releases extend
lifecycle.  Not the end of the world, but clearly we'd be deviating
from the rest of the software world.

>  * make the .1 point a big update bundle and not support .0 after
> that,
>    but taking the whole thing around to after the next .1 
That seems the most tenable position.

There is another problem with .0...N releases.  As soon as you version
your main release like that, everyone assumes .0 is unstable or broken
and they wait for .1.  Some wait for .2 (which doesn't exist in your
proposal but clearly could).  This is a perception problem more than
anything, but it exists and is quite common.  In products that have a
multi-year lifespan that isn't ideal but it also isn't the end of the
world.  It just means your adoption curves look similar to Fedora's
today and the end result is that the majority of your users are
migrated when that release is well into its support lifecycle.

In a Fedora world, it means your .0 release gains limited adoption,
with .1 being more popular (OK so far), but then M.0 comes out in 6mo
and you reset.  Essentially you've adjusted your adoption rate to
spike on the .1 updates, and artificially limited the userbase of that
major release.  That in turn limits the testing and deployment
opportunities which limits the fixes you can get into .1 to make it
better.  I'm not sure that's a net win.

>  Rawhide is a good question. I'd like to see the
> more-stable-rawhide
>  ("Bikeshed!") idea in place, and hopefully more people running that,
>  making it more likely that Rawhide is at a good place for stabilization
>  when we branch for the annual release. 
The simple answer there is that Rawhide becomes your (gated) rolling
release, and the releases deviate from it by stability and lifecycle.
This is essentially what SuSE has done with Tumbleweed and Leap,
respectively.

josh

[Matthew Miller]

On Mon, Dec 05, 2016 at 05:01:24PM -0500, Josh Boyer wrote:
>  There is another problem with .0...N releases.  As soon as you
> version
>  your main release like that, everyone assumes .0 is unstable or broken
>  and they wait for .1.  Some wait for .2 (which doesn't exist in your
>  proposal but clearly could).  This is a perception problem more than
>  anything, but it exists and is quite common.  In products that have a
>  multi-year lifespan that isn't ideal but it also isn't the end of the
>  world.  It just means your adoption curves look similar to Fedora's
>  today and the end result is that the majority of your users are
>  migrated when that release is well into its support lifecycle. 
Good point. So, I guess, another way to do this — especially if we like
the "it's a big batched update" approach rather than having split
lifecycles — would be to not call 'em .0 and .1 but keep to the integer
version numbers released in June and call the update bundle some
arbitrary name like "November Update".

Or we could just use .a and .b instead of .0 and .1. Or .j and .n for
June and November.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Chris Murphy]

On Mon, Dec 5, 2016 at 3:18 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 05:01:24PM -0500, Josh Boyer wrote:
> > There is another problem with .0...N releases.  As soon as you version
> > your main release like that, everyone assumes .0 is unstable or broken
> > and they wait for .1.  Some wait for .2 (which doesn't exist in your
> > proposal but clearly could).  This is a perception problem more than
> > anything, but it exists and is quite common.  In products that have a
> > multi-year lifespan that isn't ideal but it also isn't the end of the
> > world.  It just means your adoption curves look similar to Fedora's
> > today and the end result is that the majority of your users are
> > migrated when that release is well into its support lifecycle.
>
>  Good point. So, I guess, another way to do this — especially if we like
>  the "it's a big batched update" approach rather than having split
>  lifecycles — would be to not call 'em .0 and .1 but keep to the integer
>  version numbers released in June and call the update bundle some
>  arbitrary name like "November Update".
>
>  Or we could just use .a and .b instead of .0 and .1. Or .j and .n for
>  June and November. 
Fedora 26
Fedora 26 +1 (which maybe confusing ≠ 27 but we're always +1'ing
things around here, so it sorta fits)


-- 
Chris Murphy

[Stephen John Smoogen]

On 5 December 2016 at 17:18, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 05:01:24PM -0500, Josh Boyer wrote:
> > There is another problem with .0...N releases.  As soon as you version
> > your main release like that, everyone assumes .0 is unstable or broken
> > and they wait for .1.  Some wait for .2 (which doesn't exist in your
> > proposal but clearly could).  This is a perception problem more than
> > anything, but it exists and is quite common.  In products that have a
> > multi-year lifespan that isn't ideal but it also isn't the end of the
> > world.  It just means your adoption curves look similar to Fedora's
> > today and the end result is that the majority of your users are
> > migrated when that release is well into its support lifecycle.
>
>  Good point. So, I guess, another way to do this — especially if we like
>  the "it's a big batched update" approach rather than having split
>  lifecycles — would be to not call 'em .0 and .1 but keep to the integer
>  version numbers released in June and call the update bundle some
>  arbitrary name like "November Update".
>
>  Or we could just use .a and .b instead of .0 and .1. Or .j and .n for
>  June and November. 
No there needs to be up to 3 .'s... then we can bring back the days of
Red Hat Linux where Fedora 26.0 is the big changes for the release,
26.1 is an incremental change 26.2 is the one we plan to support as
our LTS and we start working on .0 again..

And we can have ponies for everyone too :). [Please take the second
part of the proposal as seriously as the first.]

>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Kamil Paral]

>  On Mon, Dec 05, 2016 at 05:01:24PM -0500, Josh Boyer wrote:
>  > There is another problem with .0...N releases.  As soon as you version
>  > your main release like that, everyone assumes .0 is unstable or broken
>  > and they wait for .1.  Some wait for .2 (which doesn't exist in your
>  > proposal but clearly could).  This is a perception problem more than
>  > anything, but it exists and is quite common.  In products that have a
>  > multi-year lifespan that isn't ideal but it also isn't the end of the
>  > world.  It just means your adoption curves look similar to Fedora's
>  > today and the end result is that the majority of your users are
>  > migrated when that release is well into its support lifecycle.
>  
>  Good point. So, I guess, another way to do this — especially if we like
>  the "it's a big batched update" approach rather than having split
>  lifecycles — would be to not call 'em .0 and .1 but keep to the integer
>  version numbers released in June and call the update bundle some
>  arbitrary name like "November Update".
>  
>  Or we could just use .a and .b instead of .0 and .1. Or .j and .n for
>  June and November. 
With my QA hat on, I believe using decimal releases (integers, characters or anything
else) is a bad idea. The reason is that people don't remember it. Most people remember
whether they have Fedora 22/23/24 or Windows 7/8/10. But they almost never remember
whether they have 23.0 or 23.1. At least that was my experience when I was involved in
Ubuntu in the past - when we asked "what version of Ubuntu do you have?" the
answer has in 99% of cases was "Ubuntu 12". And then we had to follow up
"12.04 or 12.10?" (those two being completely different releases of course, as
in Fedora 23 vs 24). And then "I don't know, how do I find out?". This
conversation starter was there almost every single freaking time, a huge time waster.
Decimal points are a nice idea, but people just. don't. remember. (or perhaps ignore
it as insignificant). I'd rather keep Fedora releases as integers, even if we decide
to implement some of that what was proposed.

Unless... unless we can bring back "Beefy Miracle"-like codenames as the big
update names. Then I'd consider it, just for the fun involved ;-)

[Matthew Miller]

On Tue, Dec 06, 2016 at 09:00:35AM -0500, Kamil Paral wrote:
>  With my QA hat on, I believe using decimal releases (integers,
>  characters or anything else) is a bad idea. The reason is that people
>  don't remember it. Most people remember whether they have Fedora 
Assuming we're generally leading towards "point release is basically a
big batched update", that's actually a feature. We wouldn't even really
have to increase the version number at all.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jeremy Newton]

I feel like the batched update makes a lot of sense, providing the same amount of
QA/testing time is still provided and some rules are set on what can and cannot be pushed
in that update. E.g., since GTK now has a LTS model, I would assume major release updates
would only ever be pushed to rawhide or pre-release branches?

As well, how would this be implemented? A new branch that we push major updates to certain
packages? Or will we have some core app/library maintainers (such as for GNOME or KDE)
that will push one big update to testing half way through a release's life?

[Peter Robinson]

On Tue, Dec 6, 2016 at 8:15 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Dec 06, 2016 at 09:00:35AM -0500, Kamil Paral wrote:
> > With my QA hat on, I believe using decimal releases (integers,
> > characters or anything else) is a bad idea. The reason is that people
> > don't remember it. Most people remember whether they have Fedora
>
>  Assuming we're generally leading towards "point release is basically a
>  big batched update", that's actually a feature. We wouldn't even really
>  have to increase the version number at all. 
If you're going this way why not just leave the version number the
same and just re-spin all the release artifacts with the latest
components. That way you don't need to deal with branching etc as it
can all just happen on the same branch. You could then even do it as a
quarterly batched update, likely useful for security/bug fixes etc for
live/arm/cloud images too.

[Stephen John Smoogen]

On 6 December 2016 at 09:00, Kamil Paral <kparal(a)redhat.com&gt; wrote:
> > On Mon, Dec 05, 2016 at 05:01:24PM -0500, Josh Boyer wrote:
> > > There is another problem with .0...N releases.  As soon as you version
> > > your main release like that, everyone assumes .0 is unstable or broken
> > > and they wait for .1.  Some wait for .2 (which doesn't exist in your
> > > proposal but clearly could).  This is a perception problem more than
> > > anything, but it exists and is quite common.  In products that have a
> > > multi-year lifespan that isn't ideal but it also isn't the end of the
> > > world.  It just means your adoption curves look similar to Fedora's
> > > today and the end result is that the majority of your users are
> > > migrated when that release is well into its support lifecycle.
> >
> > Good point. So, I guess, another way to do this — especially if we like
> > the "it's a big batched update" approach rather than having split
> > lifecycles — would be to not call 'em .0 and .1 but keep to the integer
> > version numbers released in June and call the update bundle some
> > arbitrary name like "November Update".
> >
> > Or we could just use .a and .b instead of .0 and .1. Or .j and .n for
> > June and November.
>
>  With my QA hat on, I believe using decimal releases (integers, characters or anything
> else) is a bad idea. The reason is that people don't remember it. Most people remember
> whether they have Fedora 22/23/24 or Windows 7/8/10. But they almost never remember
> whether they have 23.0 or 23.1. At least that was my experience when I was involved in
> Ubuntu in the past - when we asked "what version of Ubuntu do you have?" the
> answer has in 99% of cases was "Ubuntu 12". And then we had to follow up
> "12.04 or 12.10?" (those two being completely different releases of course, as
> in Fedora 23 vs 24). And then "I don't know, how do I find out?". This
> conversation starter was there almost every single freaking time, a huge time waster.
> Decimal points are a nice idea, but people just. don't. remember. (or perhaps ignore
> it as insignificant). I'd rather keep Fedora releases as integers, even if we decide
> to implement some of that what was proposed.
>  
I am used to a similar problem with RHEL/CentOS world.. a lot of
people will say they are on RHEL-6.3 or 7.1 even though they have
updated to the day they ask for a problem. That version was required
or written down and that is what they will say it is period. I expect
that no matter what you call the .release people will refer to the
major number and be confused that there could be different versions


>  Unless... unless we can bring back "Beefy Miracle"-like
> codenames as the big update names. Then I'd consider it, just for the fun involved
> ;-)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Chris Murphy]

On Mon, Dec 5, 2016 at 3:01 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:

>  There is another problem with .0...N releases.  As soon as you
> version
>  your main release like that, everyone assumes .0 is unstable or broken
>  and they wait for .1.  Some wait for .2 (which doesn't exist in your
>  proposal but clearly could).  This is a perception problem more than
>  anything, but it exists and is quite common.  In products that have a
>  multi-year lifespan that isn't ideal but it also isn't the end of the
>  world.  It just means your adoption curves look similar to Fedora's
>  today and the end result is that the majority of your users are
>  migrated when that release is well into its support lifecycle.
>
>  In a Fedora world, it means your .0 release gains limited adoption,
>  with .1 being more popular (OK so far), but then M.0 comes out in 6mo
>  and you reset.  Essentially you've adjusted your adoption rate to
>  spike on the .1 updates, and artificially limited the userbase of that
>  major release.  That in turn limits the testing and deployment
>  opportunities which limits the fixes you can get into .1 to make it
>  better.  I'm not sure that's a net win. 
I think that's become somewhat quaint in practice, as most people have
been opting in to Apple's annual macOS updates within a month of
release for some time now. The same is effectively true on Windows 10
(aside from the more compulsory/trickery aspect). There's a deemphasis
on the fact it's a .0 release also. It's X number without a .0, and
only gets .1, .2 and so on.



> > Rawhide is a good question. I'd like to see the more-stable-rawhide
> > ("Bikeshed!") idea in place, and hopefully more people running that,
> > making it more likely that Rawhide is at a good place for stabilization
> > when we branch for the annual release.
>
>  The simple answer there is that Rawhide becomes your (gated) rolling
>  release, and the releases deviate from it by stability and lifecycle.
>  This is essentially what SuSE has done with Tumbleweed and Leap,
>  respectively. 
Although Leap is based off SLE rather than Tumbleweed, older kernels
and such, plus some more stable newer things from Tumbleweed.


-- 
Chris Murphy

[Peter Robinson]

On Mon, Dec 5, 2016 at 9:26 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 05, 2016 at 01:43:58PM -0700, Chris Murphy wrote:
> > I'm not sure it's much harder to do without modularity. Right now
> > Fedora could do a Fedora 26 release without any conventional release
> > media for server and workstation, by just using dnf system-upgrade and
> > gnome-software. And in a sense that's more like how the incremental
> > release for rpm-ostree based installations end up working out anyway.
>
>  True.
>
> > Would Fedora 26.1 be a branch off Rawhide, or a branch off Fedora 26
> > with relaxed rules about what sorts of things can be significantly
> > updated? A huge part of the effort for each release is sun baking the
> > rawhide. And what effect does a once a year major release have on
> > Rawhide? Or what effect do we want it to have?
>
>  I was thinking a branch off of 26 with relaxed rules. I'm not sure what
>  the EOL policy would be like — could be any of
>
>  * treat both .0 and .1 releases as we do full releases now (which would
>    make each release go EOL a month after the *next* .0 or .1)
>  * end the .1 release support at the same time .0 ends
>  * make the .1 point a big update bundle and not support .0 after that,
>    but taking the whole thing around to after the next .1
>
>  Rawhide is a good question. I'd like to see the more-stable-rawhide
>  ("Bikeshed!") idea in place, and hopefully more people running that,
>  making it more likely that Rawhide is at a good place for stabilization
>  when we branch for the annual release. 
Which is fine if you have all the CI/automated testing in place to
ensure that is the case. We currently do not. Just look at the last
few weeks of rawhide based on mailing list threads. The core desktop
has issues, there was issues with ssh due to selinux regressions....
and sure all this could be gated and handled with CI and test
harnesses but we don't currently have them and I don't see enough
resources in the short term to make this a viable proposal.

Add to this you can get yourself in a situation where some core
enhancements wouldn't land in a stable release for 15-18 months! We
saw this in the F-21 cycle. For example. F-26 branches late Jan /
beginning of Feb, new feature that needs a mass rebuild (say CFLAGS
security hardening as an example) lands just after branching to ensure
max time to deal with regressions, that wouldn't land in a new stable
release until June the following year!! Now given that could have been
in development upstream for a good 6+ months before hand we could be
shipping features _YEARS_ after they're considered cool!

Now for my new role of IoT and plan to use Fedora as a base for
development you put me in a interesting situation.... I either have to
use rawhide without a history of gating and being a stable rolling
release, not ideal, or use a stable release that might not have all
the bits I need in terms of latest greatest security stuff, or I have
to allocate resources to backport that to the stable release and hope
we don't break other users in the process and spend considerable
resources in doing so.... else we fork off rawhide at certain points
that suit us based on particular features we need/want and spend
considerable resources dealing with that. Frankly none of the three
options are particularly palatable to me with the quick thought I've
put into this (I am actually on PTO and shockingly actually been AFK).

I think the proposal would eventually be doable _ONCE_ we have a
stable rolling rawhide release. I would actually really like to base
my work on rolling rawhide with ostree/atomic but only once we have a
CI/test/QE platform and gating to ensure it is a constantly stable
(sure mistakes/issues do happen) platform to base stuff on. Yes, I do
plan to have resources to assist in contributing to that functionality
but I think at the moment you're trying to put the horse before the
cart just to deal with a stats problem where you could just look at
the numbers a different way while ensuring the infrastructure to
support a proposal such as the above is actually there and usable.

Peter

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 05, 2016 at 09:47:43AM -0500, 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 
Can you publish the data that was used to make this graph?
(I don't mean the raw logs, just the table of #IPs vs date vs release)

Zbyszek

[Matthew Miller]

On Tue, Dec 06, 2016 at 12:59:41AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  Can you publish the data that was used to make this graph?
>  (I don't mean the raw logs, just the table of #IPs vs date vs release) 
We don't want to expose the IP addresses. Actually, *I* don't even see
them. Is there a particular question you'd like me to look at or have
looked at, though?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 05, 2016 at 08:10:39PM -0500, Matthew Miller wrote:
>  On Tue, Dec 06, 2016 at 12:59:41AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > Can you publish the data that was used to make this graph?
>  > (I don't mean the raw logs, just the table of #IPs vs date vs release)
>  
>  We don't want to expose the IP addresses. Actually, *I* don't even see
>  them. Is there a particular question you'd like me to look at or have
>  looked at, though? 
I don't. That's why I wrote that I want to see the number of IPs (not IP numbers
;)).
Basically, I want to display your graphs in a slightly different way.

Zbyszek

[Stephen John Smoogen]

On 5 December 2016 at 19:59, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, Dec 05, 2016 at 09:47:43AM -0500, 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
>
>  Can you publish the data that was used to make this graph?
>  (I don't mean the raw logs, just the table of #IPs vs date vs release) 
You are looking for a csv file of the data?


>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 05, 2016 at 09:47:23PM -0500, Stephen John Smoogen wrote:
>  On 5 December 2016 at 19:59, Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  > On Mon, Dec 05, 2016 at 09:47:43AM -0500, 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
>  >
>  > Can you publish the data that was used to make this graph?
>  > (I don't mean the raw logs, just the table of #IPs vs date vs release)
>  
>  You are looking for a csv file of the data? 
Yeah.

Zbyszek

[Dennis Gilmore]

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

[Peter Robinson]

On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; 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 be interested in seeing total number of Fedora users on a
supported release over time. I think that is a more useful, or at
least equally useful stat, than up take of a new GA release. Users
upgrade at different times for different reasons and I don't think
focus on N vs N-1 is always useful. Data like active users of stable
(or maybe current releases to include the one about to go GA) releases
the month prior to a new release (so 23/24/what will become 25), the
month of overlap (ie 3 stable releases) and the month after 23 goes
EOL (so remove 23 from stats to see if there's any drop off, whether
it recovers in the time post EOL) is a extremely useful data point,
and also the total stable users over time to see how our overall user
base is growing.

P

[Stephen John Smoogen]

On 8 December 2016 at 19:30, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller
> <mattdm(a)fedoraproject.org&gt; 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 be interested in seeing total number of Fedora users on a
>  supported release over time. I think that is a more useful, or at
>  least equally useful stat, than up take of a new GA release. Users
>  upgrade at different times for different reasons and I don't think
>  focus on N vs N-1 is always useful. Data like active users of stable
>  (or maybe current releases to include the one about to go GA) releases 
Is this like what you want?

https://smooge.fedorapeople.org/fedora-stacked-ma.png

>  the month prior to a new release (so 23/24/what will become 25), the
>  month of overlap (ie 3 stable releases) and the month after 23 goes
>  EOL (so remove 23 from stats to see if there's any drop off, whether
>  it recovers in the time post EOL) is a extremely useful data point,
>  and also the total stable users over time to see how our overall user
>  base is growing.
>
>  P
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Peter Robinson]

On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On 8 December 2016 at 19:30, Peter Robinson
> <pbrobinson(a)gmail.com&gt; wrote:
> > On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> 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 be interested in seeing total number of Fedora users on a
> > supported release over time. I think that is a more useful, or at
> > least equally useful stat, than up take of a new GA release. Users
> > upgrade at different times for different reasons and I don't think
> > focus on N vs N-1 is always useful. Data like active users of stable
> > (or maybe current releases to include the one about to go GA) releases
>
>  Is this like what you want?
>
>  https://smooge.fedorapeople.org/fedora-stacked-ma.png 
Possibly, looks closeish, does that include EPEL?

P

[Stephen John Smoogen]

On 8 December 2016 at 20:00, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen
> <smooge(a)gmail.com&gt; wrote:
> > On 8 December 2016 at 19:30, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
> >> On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> 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 be interested in seeing total number of Fedora users on a
> >> supported release over time. I think that is a more useful, or at
> >> least equally useful stat, than up take of a new GA release. Users
> >> upgrade at different times for different reasons and I don't think
> >> focus on N vs N-1 is always useful. Data like active users of stable
> >> (or maybe current releases to include the one about to go GA) releases
> >
> > Is this like what you want?
> >
> > https://smooge.fedorapeople.org/fedora-stacked-ma.png
>
>  Possibly, looks closeish, does that include EPEL?
>  
No that is a separate data set.

>  P
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Pierre-Yves Chibon]

On Thu, Dec 08, 2016 at 08:04:14PM -0500, Stephen John Smoogen wrote:
>  On 8 December 2016 at 20:00, Peter Robinson
> <pbrobinson(a)gmail.com&gt; wrote:
>  > On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen <smooge(a)gmail.com&gt;
> wrote:
>  >> On 8 December 2016 at 19:30, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  >>> On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller
> <mattdm(a)fedoraproject.org&gt; 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 be interested in seeing total number of Fedora users on a
>  >>> supported release over time. I think that is a more useful, or at
>  >>> least equally useful stat, than up take of a new GA release. Users
>  >>> upgrade at different times for different reasons and I don't think
>  >>> focus on N vs N-1 is always useful. Data like active users of stable
>  >>> (or maybe current releases to include the one about to go GA) releases
>  >>
>  >> Is this like what you want?
>  >>
>  >> https://smooge.fedorapeople.org/fedora-stacked-ma.png
>  >
>  > Possibly, looks closeish, does that include EPEL?
>  >
>  
>  No that is a separate data set. 
The title of the graph might need a little adjustment :)


Pierre

[Stephen John Smoogen]

On 9 December 2016 at 07:58, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

> >
> > No that is a separate data set.
>
>  The title of the graph might need a little adjustment :) 
Ah thanks. I have fixed the title and added a reverse stacked graph

https://smooge.fedorapeople.org/fedora-all-stacked-ma.png

https://smooge.fedorapeople.org/fedora-rev-all-stacked-ma.png
>  Pierre
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Scott Schmit]

On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
>  Ah thanks. I have fixed the title and added a reverse stacked graph
>  
>  https://smooge.fedorapeople.org/fedora-all-stacked-ma.png 
What happened in late 2014?

[Stephen John Smoogen]

On 9 December 2016 at 16:06, Scott Schmit <i.grok(a)comcast.net&gt; wrote:
>  On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen
> wrote:
> > Ah thanks. I have fixed the title and added a reverse stacked graph
> >
> > https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
>
>  What happened in late 2014? 
We dropped SSLv2 and SSLv3 and some TLS algorithms. This dropped a lot
of clients who were already 'end of lifed' from checking in. [They may
still be trying but handshake not happening etc.]



>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  


-- 
Stephen J Smoogen.

[Matthew Miller]

On Fri, Dec 09, 2016 at 04:21:27PM -0500, Stephen John Smoogen wrote:
>  >> Ah thanks. I have fixed the title and added a reverse
> stacked graph
>  >> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
>  > What happened in late 2014?
>  We dropped SSLv2 and SSLv3 and some TLS algorithms. This dropped a lot
>  of clients who were already 'end of lifed' from checking in. [They may
>  still be trying but handshake not happening etc.] 
This dropped measurement Fedora 12, 13, 14, and 15 by about 95%
overnight. For whatever reason, did not affect F11 and earlier, or
later.

There's no particular reason to expect that F12-F15 do anything but
follow the very slow long tail decline we see in releases before and
after that, and so for reports where I'm showing a pretty overall
picture — or when trying to answer questions like "how many legacy
systems vs. current or recent releases"? I usually use a projected
value.

I don't have an excellent explanation for the drop we saw *this*
summer, except the observation (from another dataset) that it seems to
be mostly a drop in i686 while x86_64 is still growing.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
>  On 9 December 2016 at 07:58, Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
>  
>  >>
>  >> No that is a separate data set.
>  >
>  > The title of the graph might need a little adjustment :)
>  
>  Ah thanks. I have fixed the title and added a reverse stacked graph
>  
>  https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
>  
>  https://smooge.fedorapeople.org/fedora-rev-all-stacked-ma.png 
What's with the numbering: fed27, fed28, fed29?

Zbyszek

[M. Edward (Ed) Borasky]

1. I've long been a fan of rolling releases; it's only the fear of having to
rebuild my workstation / laptop occasionally that keeps me from running Rawhide by
default.

2. I don't think it's the release schedule that impacts Fedora's popularity
relative to Ubuntu. Ubuntu is popular because third parties test there first, and CentOS /
RHEL second. If they have spare test resources, they'll do Debian or SUSE Linux
Enterprise before they'll do Fedora.

So I would make Fedora something like openSUSE Tumbleweed- a rolling release with heavy
automated QA. That way you get your latest desktop, compilers and kernel with much less
data loss risk than Rawhide (or openSUSE "Factory", to keep the analogy.) 

To satisfy the people who want an every-two-years-with-five-year-support distro like
Ubuntu's LTS, incorporate that philosophy into RHEL and CentOS. This seems to me to be
simply a matter of reallocating people and machines. I don't know why one would run
Fedora on a server, even a stable release, without a long-term support capability.

I spent most of the time between Fedora 24 and Fedora 25 releases on Ubuntu 16.04 LTS,
mostly because of the third-party testing issue. Their GNOME 3 desktop is seriously
pain-provoking and I went back to Fedora once F25 was released and I finished the project
I was working on to the point where I could do everyting in a virtual machine. 

But I'll probably *never* run a Fedora Docker image - there's just so much more
out there already existing on Alpine, Debian or Ubuntu. I'll most likely *never* run a
Fedora Project Atomic host, or a Fedora Amazon / Google Cloud / Digital Ocean instance.