4:32 p.m.
It's worth noting that the following already appear to "rolling"
components:
Linux Kernel
Firefox (forced by upstream policies)
LibreOffice
Wine
They are all upgraded to the latest stable version, quite regularly for the
currently stable supported release (F16), and I believe for older supported
releases on a best effort basis.
It makes sense to me that as other software gets to be as easily upgraded
as the above, they would become rolling as well. That's not to say
upgrading those are easy for the developers, but they are on us users (for
the most part).
I actually run more Fedora desktops now because those components are always
upgraded, and those are the components I care about.
Thanks,
Bryan
5:40 p.m.
Bryan Quigley wrote:
It's worth noting that the following already appear to
"rolling"
components:
Linux Kernel
Firefox (forced by upstream policies)
LibreOffice
Wine
The funny thing is that Firefox and OpenOffice.org used to be the examples
(along with GNOME) brought up by the proponents of the current stable update
policies to prove that it's common practice to not upgrade to the latest
version in stable updates…
I think a more flexible upgrade policy (i.e. explicitly encouraging upgrades
of that kind rather than discouraging them as is the case now) would be a
much better solution than a true rolling release. You'd get the new stuff
without the breakage!
Kevin Kofler
1:50 a.m.
On Tue, Jan 24, 2012 at 05:32:27PM -0500, Bryan Quigley wrote:
It's worth noting that the following already appear to
"rolling" components:
LibreOffice
They are all upgraded to the latest stable version, quite regularly for the
currently stable supported release (F16), and I believe for older supported
releases on a best effort basis.
Sorry, but that is not true. We only push _bugfix_ releases to released
Fedoras. If you look at the packages, you will see that there is 3.3.4
in F-15, 3.4.4 in F-16 (3.4.5 update is going to go out in a short time)
and 3.5.0 rc1 in Rahwide (rc2 is being built right now). We do not plan
to update F-15 to 3.4.5 or F-16 to 3.5.0, when it goes out.
D.
7:22 p.m.
Oh, then I guess I would like to see LibreOffice be a rolling
component. I guess one of the questions is why rolling for these:
Linux Kernel
Firefox (forced by upstream policies)
Wine
and not for others?
On Wed, Jan 25, 2012 at 2:50 AM, David Tardon <dtardon(a)redhat.com> wrote:
On Tue, Jan 24, 2012 at 05:32:27PM -0500, Bryan Quigley wrote:
> It's worth noting that the following already appear to "rolling"
components:
> LibreOffice
>
> They are all upgraded to the latest stable version, quite regularly for the
> currently stable supported release (F16), and I believe for older supported
> releases on a best effort basis.
Sorry, but that is not true. We only push _bugfix_ releases to released
Fedoras. If you look at the packages, you will see that there is 3.3.4
in F-15, 3.4.4 in F-16 (3.4.5 update is going to go out in a short time)
and 3.5.0 rc1 in Rahwide (rc2 is being built right now). We do not plan
to update F-15 to 3.4.5 or F-16 to 3.5.0, when it goes out.
D.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
8:02 p.m.
On 01/26/2012 06:52 AM, Bryan Quigley wrote:
Oh, then I guess I would like to see LibreOffice be a rolling
component. I guess one of the questions is why rolling for these:
Linux Kernel
Firefox (forced by upstream policies)
Wine
and not for others?
You answered your own question really
http://fedoraproject.org/wiki/Updates_Policy
Rahul
8:17 p.m.
I can understand exceptions for Firefox (but you don't want to switch
to the enterprise slow release right?), and Wine, but...
I've read it several times and I don't quite understand the major
kernel version bumps. 3.2.1 just got released to Fedora 16, yet it
started with 3.1.0.
Don't get me wrong, I really like and appreciated the updates to the
latest kernels, I just don't see how it follows the Updates Policy.
Thanks!
Bryan
On Wed, Jan 25, 2012 at 9:02 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/26/2012 06:52 AM, Bryan Quigley wrote:
> Oh, then I guess I would like to see LibreOffice be a rolling
> component. I guess one of the questions is why rolling for these:
> Linux Kernel
> Firefox (forced by upstream policies)
> Wine
>
> and not for others?
You answered your own question really
http://fedoraproject.org/wiki/Updates_Policy
Rahul
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
8:56 p.m.
On 01/26/2012 07:47 AM, Bryan Quigley wrote:
I can understand exceptions for Firefox (but you don't want to
switch
to the enterprise slow release right?), and Wine, but...
I've read it several times and I don't quite understand the major
kernel version bumps. 3.2.1 just got released to Fedora 16, yet it
started with 3.1.0.
Don't get me wrong, I really like and appreciated the updates to the
latest kernels, I just don't see how it follows the Updates Policy.
The Fedora kernel team can probably answer this better but:
"Security fixes
If upstream does not provide security fixes for a particular release,
and if backporting the fix would be impractical, then a package may be
rebased onto a version that upstream supports. The definition of
practicality is left to the judgement of FESCO and the packager."
The stable series is supposed to do this for prior version atleast for
security fixes but in practise, this doesn't work out as well and
combined Linus's sad habit of concealing security fixes and the fact
that kernel gets hundreds of bug reports requiring the maintainers to
stay close to upstream to get responsive results leaves Fedora with
rebasing as the better option.
Rahul
9:01 p.m.
On Wed, Jan 25, 2012 at 9:17 PM, Bryan Quigley <gquigs(a)gmail.com> wrote:
I can understand exceptions for Firefox (but you don't want to
switch
to the enterprise slow release right?), and Wine, but...
I've read it several times and I don't quite understand the major
kernel version bumps. 3.2.1 just got released to Fedora 16, yet it
started with 3.1.0.
It's pretty simple, really. Basically, if we don't keep the kernel on at
least a somewhat recent release the amount of work required to support
that release grows beyond what we can realistically maintain.
Let's use F16 as an example (which also applies to F15 but we'll stick
with one release for now). The 3.1.y stable series is now EOL upstream,
which means that there will be no more upstream maintenance on it at all.
No auto-backports, no security fixes, nothing. So if we were to stick
with 3.1.y for the entirety of F16, we'd be looking at roughly another
year and a half of using a kernel that upstream absolutely does not care
about. The Fedora kernel maintainers would need to weed through all of
the commits going into 3.2.y (until it goes EOL) and 3.3 and 3.4 to
figure out which fix security issues, which fix issues that hit enough
people to warrant a backport, etc. Then we'd need to backport them which
starts out easy enough but as time goes on becomes increasingly difficult.
The rate of change in the upstream kernel is ridiculous (and I mean that
in both good and bad ways) so once you get a couple of releases removed
from what we're using the "simple" fixes are heavily dependent on code
changes and subsystem reworks that went in prior to that.
You might be saying "well... isn't that your job?" The answer is, yes.
We do backports all the time, for fixes, hardware enablement, security
issues, etc. However, by rebasing frequently we're only having to do that
from usually one release away. You might also be saying "well... doesn't
RHEL do this kind of stuff too?" Sure, probably (I don't work on RHEL so
I don't really know). The difference there is in applicable manpower.
There are significantly more people working on the RHEL kernel than there
are Fedora. We have 2 engineers and some great heavy lifing from a
couple of wireless developers and a few others for topic specific bugs.
(Which reminds me, we have an immediate opening if any of this mini-novel
on kernel maintenance doesn't make you run away screaming and you want to
apply...)
One might point out that F14 stuck with the 2.6.35-longterm kernel. The
"longterm" kernels are meant to be a focal point for a number of
developers and distros to work with to help with the manpower and
backporting issues. On paper that sounds awesome. In practice, it
rarely works. 2.6.35.y has known unfixed security issues and backporting
things to it was essentially an exercise in frustration at the end. It
hasn't had a new release in a long time. The only longterm series I can
think of that somewhat works is 2.6.32.y. If you think about it for a
second you'll notice that the two largest Enterprise Linux distributions
started out based on.. 2.6.32. Correlation does not equal causation, but
I can't honestly think of any other reason that kernel continues to
interest people. Even that longterm kernel is about to change upstream
maintainers because it's getting really long in the tooth now.
So by rebasing frequently, we limit the amount of work required to
actually fix issues that our users see. We also get new hardware
enablement from the newer kernels, and new features. Perhaps most
importantly, we stay relevant to upstream so that when we find bugs in
their work it's still fresh in their memories and we can possibly shame
them into providing fixes instead of being laughed at for using a kernel
that is 2 releases old.
Hopefully that helps explain what we're thinking when we go about doing
what we do. As usual, sorry for being overly verbose.
josh
9:46 p.m.
On 01/25/2012 10:01 PM, Josh Boyer wrote:
On Wed, Jan 25, 2012 at 9:17 PM, Bryan Quigley
<gquigs(a)gmail.com> wrote:
It's pretty simple, really. Basically, if we don't keep the kernel on at
least a somewhat recent release the amount of work required to support
that release grows beyond what we can realistically maintain.
...
Hopefully that helps explain what we're thinking when we go about doing
what we do. As usual, sorry for being overly verbose.
josh
A great explanation - and a nice summary of why a rolling release
makes sense for many of the same reasons .. :-)
thanks josh!
PS - special thanks to you and the kernel team for doing a great job
keeping the kernel up to date and purring nicely ...
11:22 p.m.
On Wed, Jan 25, 2012 at 10:46:42PM -0500, Genes MailLists wrote:
On 01/25/2012 10:01 PM, Josh Boyer wrote:
> On Wed, Jan 25, 2012 at 9:17 PM, Bryan Quigley <gquigs(a)gmail.com> wrote:
>
> It's pretty simple, really. Basically, if we don't keep the kernel on at
> least a somewhat recent release the amount of work required to support
> that release grows beyond what we can realistically maintain.
...
> Hopefully that helps explain what we're thinking when we go about doing
> what we do. As usual, sorry for being overly verbose.
A great explanation - and a nice summary of why a rolling release
makes sense for many of the same reasons .. :-)
Except that this doesn't burn people often because Linus is also *very*
strict about interface changes between the kernel & userspace.
Can you say the same about GNOME? KDE? gcc? subversion? (Yes, they have
rules about when they're allowed to break backward compatibility, but
they are allowed to do it at certain version changes.)
Somehow I doubt you'll be very happy with your rolling release if you
update your machine right before a major customer demo or other Big
Important Time-Sensitive Event, and the thing(s) you need to make it
happen break--not because of bugs, but because unwanted "features" like
configuration file changes, ABI changes, etc made your stuff stop
working until you stop everything and fix whatever changed.
--
Scott Schmit
11:09 a.m.
On Thu, Jan 26, 2012 at 00:22:28 -0500,
Scott Schmit <i.grok(a)comcast.net> wrote:
Except that this doesn't burn people often because Linus is also *very*
strict about interface changes between the kernel & userspace.
Hardware specific regressions aren't that rare. I have run into them
several times. I have had problems with disk controllers, USB flash
drives and video cards. Sometimes there are work arounds (e.g. using
nomodeset or disabling AGP), other times I just stayed on old kernels for a
while.
11:39 a.m.
On Thu, Jan 26, 2012 at 8:09 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
Hardware specific regressions aren't that rare. I have run into
them
several times. I have had problems with disk controllers, USB flash
drives and video cards. Sometimes there are work arounds (e.g. using
nomodeset or disabling AGP), other times I just stayed on old kernels for a
while.
And it should be pointed out, the kernel is handled as a very special
case in our packaging. We understand and expect people to have
multiple parallel installed kernel packages on system. So if and when
you do hit a hardware regression you usually have the ability to
fallback to an older kernel that was working for you because it was
not removed from the system when the new kernel was installed. The
point being, we don't make it easy to do that for other packaged
components. A fear a full rolling release would involve some deep
re-engineering of everything we package to make it possible to
parallel install multiple versions of everything.
-jef
2:50 a.m.
On Wed, Jan 25, 2012 at 9:49 AM, drago01 <drago01(a)gmail.com> wrote:
On Tue, Jan 24, 2012 at 11:32 PM, Bryan Quigley
<gquigs(a)gmail.com> wrote:
> It's worth noting that the following already appear to "rolling"
components:
> LibreOffice
Not true.
Oh David already said that ... should probably read the whole thread
before replying.
4474
days inactive
4476
days old
13 comments
10 participants
participants (10)
-
Bruno Wolff III -
Bryan Quigley -
David Tardon -
drago01 -
Genes MailLists -
Jef Spaleta -
Josh Boyer -
Kevin Kofler -
Rahul Sundaram -
Scott Schmit