Weekly Edition
Return to the Distributions pageRecent Features
| |||||||||||||||||||
Fedora's "stable release updates vision"
As noted in our previous minutes[1], the Board was tasked with producing a vision statement for updates to Fedora stable releases. That vision can be found here: https://fedoraproject.org/wiki/Stable_release_updates_vision This statement is the result of many Board discussions which have taken into consideration issues raised recently in numerous other venues such as the devel list. After considering these issues carefully, along with other factors such as the broad user base for which we should strive[2], the Board feels this vision will best meet the needs of our millions of users, including our contributor base. The Board would like FESCo to read through this vision statement, and use it as a basis for implementing changes that will help achieve this vision. We look forward to working with FESCo and across the whole Fedora Project to continue improving the Fedora distribution. * * * [1] http://meetbot.fedoraproject.org/fedora-board-meeting/201... [2] https://www.redhat.com/archives/fedora-advisory-board/200... -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com (Log in to post comments)
Fedora's "stable release updates vision" Posted Mar 12, 2010 15:38 UTC (Fri) by lwkejrlej (guest, #64237) [Link] Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues.This is a welcome change. It's certainly not nice to apply updates only to find out at the next reboot that the network connection is broken. PS. The timing of this change is rather suspicious. Fedora has had the "broken updates" problem since day 1. Surely this has nothing to do with RHEL 6 being around the corner, and hence Red Hat no longer requiring guinea pigs ?
Fedora's "stable release updates vision" Posted Mar 12, 2010 15:52 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Ah, the great conspiracy except that Red Hat is directing nothing at all in
this whole discussion and does it's own branching and testing for enterprise linux and that includes a lot of things that are important to the customers and not to the community.
If what you claim is a plausible scenario, how do you expect Red Hat to do
Fedora's "stable release updates vision" Posted Mar 13, 2010 8:05 UTC (Sat) by lwkejrlej (guest, #64237) [Link] If what you claim is a plausible scenario, how do you expect Red Hat to do the testing for RHEL 7?RHEL 7 is very far away, and will also need compelling new features and/or performance over RHEL 6 to convince enterprise customers (who don't like changes). Furthermore, given that the time taken between RHEL releases has been increasing, we shouldn't expect RHEL 7 for at least 5 years. (If my maths is right, RHEL 3 -> 4 took about 15 months, 4 -> 5 took roughly 25 months, 5 -> 6 will take about 40 months if released mid-2010. If the rate of slowdown is steady, RHEL 7 will take approximately 64 months -- sometime late 2015) Compared to the amount of ground covered already, the number of important things left to do in the Linux ecosystem isn't that much: the major items are btrfs, finishing the video drivers (KMS based) and real-time operation of the kernel. Given that Red Hat's focus is enterprise (i.e. no interest/no money to be made in the desktop), btrfs can be backported into a 6.x release, which means that there isn't really much in terms of new features for RHEL 7. Given this state of affairs, it's no wonder Red Hat isn't so worried about the pace of Fedora development anymore, and can "afford" to significantly decrease the reliance on Fedora being a proving ground.
Fedora's "stable release updates vision" Posted Mar 14, 2010 7:50 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Your explanation has one major gap that you didn't really answer, can you
show that Red Hat is driving this change? I doubt it. Can you really show that Fedora as upstream for Red Hat Enterprise Linux requires Fedora to push major changes as updates as opposed to the development branch? I doubt that as well. Here is an alternative explanation:
RHEL's lifecycle is Red Hat product management decision and the combination
Meanwhile, the Fedora community has itself decided to change the update
Fedora's "stable release updates vision" Posted Mar 12, 2010 15:52 UTC (Fri) by epa (subscriber, #39769) [Link]
It is better not to explain by conspiracy theory anything which can equally be explained as a cock-up.
Fedora's "stable release updates vision" Posted Mar 12, 2010 15:53 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Maybe, but more likely the timing has to do with the recent wars on both the Fedora and kernel lists, in which everyone was bashing Fedora in the strongest terms for what they've been doing lately.
I want newer stuff all the time Posted Mar 12, 2010 16:33 UTC (Fri) by dowdle (subscriber, #659) [Link]
Well, I'm disappointed... but I would have been surprised had they decided to go any other way.
I like the fact that historically Fedora has released new versions of KDE shortly after the KDE folks had. That looks like it will become a thing of the past... but I doubt it. Does that lead to breakage sometimes? Yes... although it is mostly minor.
What I'm guessing will happen is that we'll just have one or more additional repos spring up so people like me can get the newer packages that we want. If those repos aren't provided by Fedora, they will be from third parties.
A lot of times newer versions are where bug fixes take place... but since they are not fond of new versions now, I guess that in many cases we'll just have to live with the bugs... which isn't unique to Fedora.
You'll recall that a lot of Debian users (mostly desktop) prefer the unstable branch. Is it they like that it is unstable? Of course not. They like it because it offers newer stuff.
I want newer stuff all the time Posted Mar 12, 2010 16:42 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Since newer versions of KDE are first packaged and made available in kde-
redhat.sf.net repository even now before they hit the official updates- testing repo, that practice can continue as far as KDE is concerned but I agree that other repositories for packages in demand are bound to pop up.
Fedora infrastructure could potentially handle this via
I want newer stuff all the time Posted Mar 12, 2010 17:05 UTC (Fri) by hughmerz (guest, #34252) [Link] The vision statement suggests that users in your position should consider using the rawhide (continuous) release. I welcome the stance that has been taken as I think it encourages more involvement in Fedora at all levels.
I want newer stuff all the time Posted Mar 12, 2010 18:11 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Don't be so disapointed... the new rolling rawhide policy provides "latest and greatest" all the time.
I want newer stuff all the time Posted Mar 13, 2010 16:24 UTC (Sat) by BobT (guest, #37148) [Link]
>I like the fact that historically Fedora has released new versions of KDE shortly after the KDE folks had. That looks like it will become a thing of the past... but I doubt it. Does that lead to breakage sometimes? Yes... although it is mostly minor.
The change to kde-4.0 was hardly minor. Many Fedora users bailed (e.g., to Centos) after that!
I want newer stuff all the time Posted Mar 14, 2010 7:55 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
To be clear, the comment you are replying to as well as the policy changes
being talked about are related to updates only. KDE 4.0 was never pushed into any release of Fedora as an update. A new release included KDE 4.0.x as part of the release and that is outside the scope of the policy changes being discussed.
Not so new Posted Mar 14, 2010 21:42 UTC (Sun) by man_ls (subscriber, #15091) [Link] You'll recall that a lot of Debian users (mostly desktop) prefer the unstable branch.This kind of statement needs revisiting every now and then. As you can see in Debian popcon, the number of stable users has been growing steadily in the last few years. In fact it passed the number of testing/unstable users about a year ago. It seems that while sarge was hopelessly outdated for most of its tenure, lenny is current enough for about 60% of users, and about 20% each use either testing/unstable or old-stable. Debian stable is now vastly more popular than testing/unstable. Now, the graphic only shows aggregated testing+unstable users. I assume that you meant "the testing branch", since testing is vastly more popular than unstable -- however I could not find numbers to back it up.
Not so new Posted Mar 18, 2010 5:01 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
I believe this change is due to the installer now asking users whether to enable popcon. The default is still 'no', but this at least makes users aware of it. Prior to this, most users would not even have known about it so developers and enthusiasts - more likely to run testing or unstable - were over-represented.
Fedora's "stable release updates vision" Posted Mar 12, 2010 18:14 UTC (Fri) by dmitrij.ledkov (subscriber, #63320) [Link]
Debian Stable, Testing, Unstable and Experimental or Ubuntu with PPA's (especially the KDE/kubuntu ppa which give you options of both stable & unstable and experimental kde) were doing it for years.
Cool that Fedora is catching up ;-)
Fedora's "stable release updates vision" Posted Mar 13, 2010 3:32 UTC (Sat) by lipak (guest, #43911) [Link]
"More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period."
IMHO this is a difficult thing to convince users of unstable releases to do. Those who are comfortable with minor instability are not able to understand why others who want greater stability are not willing to work for it. As a result they are unwilling to take up the task of stabilising the pre-release further than that which they are doing already by report bugs/providing patches for the unstable release.
Something is very *wrong* here Posted Mar 14, 2010 17:08 UTC (Sun) by cyperpunks (subscriber, #39406) [Link]
A giant upgrade of KDE 4 has happen in Fedora 12 and it works just fine for me. Thanks!
However! Fedora users must wait 6 months for the next release to get fresh Firefox bits. That don't make sense.
What if Mac and Win users had to wait to next Service Pack / Update to get Firefox 3.6?
Something is very *wrong* here Posted Mar 14, 2010 17:16 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
You don't have to wait. Use remi's repo.
http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en
The reason it hasn't been pushed an as update is that it XULRunner changes
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Something is very *wrong* here Posted Mar 14, 2010 20:55 UTC (Sun) by cyperpunks (subscriber, #39406) [Link]
Yes, of course there ways around the problem. Using the tarball from mozilla.org seems most simple.
However, this is not the point.
This is an obvious sign that something is *fundamental* wrong in how the distribution is organised.
If the distribution can't provide the latest *stable* Firefox release in
It don't help at all to link to "No bundled libraries"-policy.
Tell a Windows user that she can't use Firefox because of the "No bundled libraries"-policy. It's insane.
Something is very *wrong* here Posted Mar 15, 2010 1:01 UTC (Mon) by bojan (subscriber, #14302) [Link]
> Tell a Windows user that she can't use Firefox because of the "No bundled libraries"-policy. It's insane.
Please point to a Microsoft application that depends on XULrunner. Please point to a Microsoft supplied mechanism of updating FF on Windows, as a "package".
You can run any latest FF on Fedora just fine. Just like on Windows. Or Mac OS X. No difference. Download, install, run. That's it.
> This is an obvious sign that something is *fundamental* wrong in how the distribution is organised.
> If the distribution can't provide the latest *stable* Firefox release in the distributions own native format and default update repos something is clearly wrong and has to change.
Distribution clearly _can_ provide latest FF updates, if it wanted to (technically). However, Fedora releases are more than just a collection of packages, as it has been explained before (many times). Wasting time on updating FF, which would then cause a cascading effect on updating many other packages is usually not warranted. So, the distro decided not to do it (most of the time). Which is fair enough.
If you so want to run the latest FF from a Fedora supplied package, download F-13 alpha. It is right there.
Something is very *wrong* here Posted Mar 15, 2010 6:45 UTC (Mon) by cyperpunks (subscriber, #39406) [Link] > Pleasepoint to a Microsoft supplied mechanism of updating FF on> Windows, as a "package". In Firefox: Choose Help -> Check updates.
Fedora has disabled this function, but now refuses to take responsbility and
> Distribution clearly _can_ provide latest FF updates Then Fedora should that ASAP, Mozilla is starting to pinging useres today about upgrade to Firefox 3.6. Firefox users http://www.theregister.co.uk/2010/0//12/mozilla_upgrade_to_firefox_3_6_nowwwwwww/ Uber Mozilla man Mike Beltzner said his team of free browser bandits were "proud" of the number of downloads Firefox 3.6 had clocked up since launch. "Starting today, users running older versions of Firefox will be offered the choice of upgrading to Firefox 3.6. Were presenting this upgrade offer for our users who may not realise that a new version is available," he said.But of course you want the > 2 million Fedora to upgrade to Fedora 13 Alpha. What kind of people want to treat their users this way?
Something is very *wrong* here Posted Mar 15, 2010 8:16 UTC (Mon) by bojan (subscriber, #14302) [Link]
> In Firefox: Choose Help -> Check updates.
Please! This is not a Microsoft solution for updating the application. It is from Mozilla and FF specific. Meaning, Windows "distro" isn't doing it either.
> Fedora has disabled this function, but now refuses to take responsbility and update to latest stable release.
You mean, when you download vanilla FF, like you do for Windows, this function is disabled? Not too sure about that. In any event, if yes, talk to Mozilla folks - nothing to do with Fedora.
Of course Fedora disables this in their package - it would break it.
> Then Fedora should that ASAP, Mozilla is starting to pinging useres today about upgrade to Firefox 3.6.
I'm sure all the packagers are hurrying to do it, now that you told them to do it ASAP ;-)
> But of course you want the > 2 million Fedora to upgrade to Fedora 13 Alpha. What kind of people want to treat their users this way?
It pays to read the posts. I said, if _you_ so want FF 3.6 packaged by Fedora, then _you_ can get it in alpha. Or, as it has been pointed out by others, from a third party repo. Or vanilla.
Doing what you are suggesting takes effort, because other packages depend on it. Sometimes (rarely), it is warranted. Mostly, it isn't.
Something is very *wrong* here Posted Mar 14, 2010 21:07 UTC (Sun) by jspaleta (subscriber, #50639) [Link]
The difficulties associated with the instability in xulrunner's API is quite instructive. It's always seemed to me that xulrunner exists sort of in an in between state between private application code and standalone reusable library.
Does webkit do a better job of managing API changes in a way that applications and distributors can anticipate?
-jef
Fedora's "stable release updates vision" Posted Mar 16, 2010 0:26 UTC (Tue) by forlwn (guest, #63934) [Link]
I agree very much with this decision.
From the moment that FOSS community realised that Linux o/s was mature enough to enter the desktop market as a big player, the Linux public image and users adherence will definitely be compromised, from a public's perspective, if its usage leads to constant system crashes or hardware failures. On this fiasco scenario it's better to forget about Linux for the desktop. Regarding updates, to keep the o/s updated, isn't it enough to have a testing and a stable public branches? Maybe also a public restricted experimental branch, too. It's pacific to expect that a minimum number of users at every testing branch will exist, allowing transfers of new version of packages to stable, in a short period of time, but only after proofed to be stable enough.
|
|||||||||||||||||||