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.
On Mon, Dec 5, 2016 at 6:47 AM, Matthew Miller mattdm@fedoraproject.org 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.
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.
On Mon, Dec 5, 2016 at 11:53 AM, Matthew Miller mattdm@fedoraproject.org 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.
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. :)
On Mon, Dec 5, 2016 at 1:10 PM, Matthew Miller mattdm@fedoraproject.org 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.
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
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.
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.
On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro mcatanzaro@gnome.org 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".
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@gnome.org 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
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?
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
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.
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...
On Tue, Dec 6, 2016 at 9:11 AM, Daniel P. Berrange berrange@redhat.com 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@gnome.org 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
On Mon, Dec 5, 2016 at 12:53 PM, Matthew Miller mattdm@fedoraproject.org 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?
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.
On Mon, Dec 5, 2016 at 2:26 PM, Matthew Miller mattdm@fedoraproject.org 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.
On Mon, Dec 5, 2016 at 4:26 PM, Matthew Miller mattdm@fedoraproject.org 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
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.
On Mon, Dec 5, 2016 at 3:18 PM, Matthew Miller mattdm@fedoraproject.org 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)
On 5 December 2016 at 17:18, Matthew Miller mattdm@fedoraproject.org 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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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 ;-)
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.
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?
On Tue, Dec 6, 2016 at 8:15 PM, Matthew Miller mattdm@fedoraproject.org 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.
On 6 December 2016 at 09:00, Kamil Paral kparal@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, Dec 5, 2016 at 3:01 PM, Josh Boyer jwboyer@fedoraproject.org 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.
On Mon, Dec 5, 2016 at 9:26 PM, Matthew Miller mattdm@fedoraproject.org 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
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
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?
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
On 5 December 2016 at 19:59, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@in.waw.pl 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
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
On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller mattdm@fedoraproject.org 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
On 8 December 2016 at 19:30, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller mattdm@fedoraproject.org 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 8 December 2016 at 19:30, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller mattdm@fedoraproject.org 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?
Possibly, looks closeish, does that include EPEL?
P
On 8 December 2016 at 20:00, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 8 December 2016 at 19:30, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller mattdm@fedoraproject.org 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?
Possibly, looks closeish, does that include EPEL?
No that is a separate data set.
P _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Dec 08, 2016 at 08:04:14PM -0500, Stephen John Smoogen wrote:
On 8 December 2016 at 20:00, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Dec 9, 2016 at 12:39 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 8 December 2016 at 19:30, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Dec 5, 2016 at 2:47 PM, Matthew Miller mattdm@fedoraproject.org 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?
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
On 9 December 2016 at 07:58, Pierre-Yves Chibon pingou@pingoured.fr 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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
What happened in late 2014?
On 9 December 2016 at 16:06, Scott Schmit i.grok@comcast.net 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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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.
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@pingoured.fr 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
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.
-
Adam Williamson -
Chris Murphy -
Daniel P. Berrange -
Dennis Gilmore -
Gerald B. Cox -
Gerald Henriksen -
Jeremy Newton -
Josh Boyer -
Kamil Paral -
M. Edward (Ed) Borasky -
Matthew Miller -
Michael Catanzaro -
Peter Robinson -
Pierre-Yves Chibon -
Scott Schmit -
Stephen John Smoogen -
Zbigniew Jędrzejewski-Szmek