Discussion:
The question of rolling release?
(too old to reply)
mike cloaked
2012-01-24 11:23:14 UTC
Permalink
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.

Three of these are:

Debian CUT:
http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
http://cut.debian.net/

Opensuse Tumbleweed:
http://en.opensuse.org/Portal:Tumbleweed

Arch Linux:
https://wiki.archlinux.org/index.php/Arch_Linux

Gentoo is also essentially a rolling release distribution.

Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.

Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
Is there a possibility that not moving to rolling release could
ultimately damage Fedora in the future as other distributions increase
their support base?

I thought this might lead to a useful discussion and this post is not
supposed to be a flame bait but a genuine question that is potentially
quite fundamental to the future of Fedora. Applying innovative and
careful thought to this question might be helpful to the Fedora
project as a whole.
--
mike c
Reindl Harald
2012-01-24 11:41:50 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
+1 if it is done right and more expermiental features with
big changes are in a repo you can disable or have to be
enabled active

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/2edc252e/attachment.sig>
Josh Boyer
2012-01-24 12:13:03 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
http://cut.debian.net/
http://en.opensuse.org/Portal:Tumbleweed
https://wiki.archlinux.org/index.php/Arch_Linux
Gentoo is also essentially a rolling release distribution.
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version.  For servers there
would be huge advantages in management of systems.
Can you list what advantages there are over doing a yum upgrade to the
next release?
Post by mike cloaked
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
Is there a possibility that not moving to rolling release could
ultimately damage Fedora in the future as other distributions increase
their support base?
How is rawhide not a rolling release? Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
Thomas Moschny
2012-01-24 12:22:00 UTC
Permalink
How is rawhide not a rolling release?  Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
This has been discussed several times on this list: Technically,
rawhide is a rolling release, sure. But rawhide is not near as stable
as it needed to be to be seriously considered for productive use.
There is no testing repo acting as a filter for example.

- Thomas
Frank Murphy
2012-01-24 12:32:04 UTC
Permalink
Post by Thomas Moschny
Post by Josh Boyer
How is rawhide not a rolling release? Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
This has been discussed several times on this list: Technically,
rawhide is a rolling release, sure. But rawhide is not near as stable
as it needed to be to be seriously considered for productive use.
There is no testing repo acting as a filter for example.
- Thomas
Create a sig\wiki page see what support you can get.
Not a "me too" page.
But a who'll step up and do the work page.
What skills\experience do they bring to your sig.
Will it bring in extra heavy-lifters,
or further dilute the current pool.

If one or two leave, will there be egg.
--
Regards,

Frank Murphy
UTF_8 Encoded
mike cloaked
2012-01-24 12:41:25 UTC
Permalink
Post by Frank Murphy
Post by Thomas Moschny
How is rawhide not a rolling release?  Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
This has been discussed several times on this list: Technically,
rawhide is a rolling release, sure. But rawhide is not near as stable
as it needed to be to be seriously considered for productive use.
There is no testing repo acting as a filter for example.
- Thomas
Create a sig\wiki page see what support you can get.
Not a "me too" page.
But a who'll step up and do the work page.
What skills\experience do they bring to your sig.
Will it bring in extra heavy-lifters,
or further dilute the current pool.
If one or two leave, will there be egg.
This was meant as a discussion in the desirability or otherwise of the
concept of rolling release. Of course manpower is required to make it
happen. However as I said in my original post other distributions have
already made the decision on the philosophy and people have stepped up
to the plate to make it happen. It is already happening in other
distros, to the question remains as to whether it is a way forward for
Fedora - the decision might be "no". In which case Fedora moves on
with its current plans unchanged. On the other hand if the decision
is "yes" then the question is whether Fedora has the available
resources to make it happen - but that is a separate issue from
answering whether or not it is desirable.

Of course Fedora is competing with other distributions - inevitably,
and indeed Fedora is supported by people who are paid by Redhat as
well as many others who work voluntarily. However if over time other
distributions gain support at the expense of Fedora/Redhat then these
questions may come back with a more urgent need to be answered in the
future. On the other hand forward planning on changes which might be
of major benefit to Fedora in the future even if they take time and
effort to implement might affect the relative position of
Fedora/Redhat compared to other linux distributions as time passes. We
live in a competitive world and brain-storming ideas that may make a
big difference in a few years is worth doing - it is important to be
ahead of the game and not responding after the event when it might be
too late!

That was why I raised the question. Clearly any change requires
majority support - and getting decisions right at an early stage is
important. I don't have the answers but I believe this discussion is
needed.
--
mike c
Frank Murphy
2012-01-24 12:57:19 UTC
Permalink
Post by mike cloaked
This was meant as a discussion in the desirability or otherwise of the
concept of rolling release.Of course manpower is required to make it
happen.
Desirability and manpower can't be seperated in some situations.
This being one. page to the sig\wiki suggestion.
Project Managment 101. Get wiki\sig
What's lacking, what can we do to fix\improve?


However as I said in my original post other distributions have
Post by mike cloaked
already made the decision on the philosophy and people have stepped up
to the plate to make it happen. It is already happening in other
distros, to the question remains as to whether it is a way forward for
Fedora - the decision might be "no". In which case Fedora moves on
with its current plans unchanged.
It may be no, due to manpower\time issues, back to sig\wiki.


On the other hand if the decision
Post by mike cloaked
is "yes" then the question is whether Fedora has the available
resources to make it happen -
You will probably get an answer based solely on this.

but that is a separate issue from
Post by mike cloaked
answering whether or not it is desirable.
.
Raher than this.
Post by mike cloaked
Of course Fedora is competing with other distributions - inevitably,
Wh?,, you use the tool that suits the job.
Be it Fedora, Ubuntu, MS, Mac et al
Post by mike cloaked
and indeed Fedora is supported by people who are paid by Redhat as
well as many others who work voluntarily.
Like some other distros.

- it is important to be
Post by mike cloaked
ahead of the game and not responding after the event when it might be
too late!
Hence the wiki\sig
Post by mike cloaked
That was why I raised the question. Clearly any change requires
majority support - and getting decisions right at an early stage is
important. I don't have the answers but I believe this discussion is
needed.
Don't discuss, do
There are probably many here who have attended meetings about meetings.
Where all it takes is, "I'll do it, John\Jane Doe might help"
and return with your prototype\iteraion.
--
Regards,

Frank Murphy
UTF_8 Encoded
mike cloaked
2012-01-24 12:30:11 UTC
Permalink
Post by Josh Boyer
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version.  For servers there
would be huge advantages in management of systems.
Can you list what advantages there are over doing a yum upgrade to the
next release?
The number of problems that have been reported to the lists for yum
upgrades seems very large. Although for any rolling release there
have been occasions where unforeseen problems have arisen the day to
day updates have been largely routine and trouble free.... hence from
what I have observed from the lists rolling releases (which of course
are generally a small percentage of the package set) are much less
problematic than one giant upgrade to all packages. Also yum
upgrades only occur once the next system version is released whereas
rolling release means that individual components can be updated as
soon as they release upstream. In Fedora for example we see systemd38
only in rawhide and not in the current f16 - so f16 users will not
have the benefit of the newest systemd until f17 is released unless
there is a major change of policy. Equally if there is a major release
of the next version of KDE or Gnome, or other major components like
the kernel there is often a delay before they are available in the
current released system. An example is that only today does kernel
3.2.1 appear in f16 repos - in arch it has been available from almost
as soon as it was released. I have been running the new kernel without
issue from the first appearance of the package.
Post by Josh Boyer
Post by mike cloaked
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
Is there a possibility that not moving to rolling release could
ultimately damage Fedora in the future as other distributions increase
their support base?
How is rawhide not a rolling release?  Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
Rawhide is often very very very unstable and only really suitable for
experienced linux users - and not for general consumption. It can
occasionally become unbootable, things can break in very major ways
and not all that infrequently - which is fine if you want to test at
the cutting edge and when new things are being developed... rolling
release is more for someone who can rely on an expectation that the
system will almost always work except on rare occasions when some
manual intervention might be needed or perhaps a package downgrade to
get going again. With rawhide I believe the expectation is that the
system can break at any time and rawhide users should not expect
stability - so a very different philosophy.

In any event rolling release can have not only stable and testing
repos, as well as devel repos, which means it is up to the user to
then choose what level of risk there is in their system - but in
choosing stable that the rolling release system it can still be much
more up to date than for many distros that release periodically, and
yet not have a major "upgrade" or re-install every 6 months - but a
much gentler path to pretty up to date major packages with only
smaller bumps most of the time and the really really nice feature that
you do not have the major hiccup of complete installs/upgrades on a
regular basis.
Post by Josh Boyer
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
mike c
Frank Murphy
2012-01-24 12:38:20 UTC
Permalink
Post by mike cloaked
The number of problems that have been reported to the lists for yum
upgrades seems very large. Although for any rolling release there
have been occasions where unforeseen problems have arisen the day to
day updates have been largely routine and trouble free.... hence from
what I have observed from the lists rolling releases (which of course
are generally a small percentage of the package set) are much less
problematic than one giant upgrade to all packages. Also yum
upgrades only occur once the next system version is released whereas
rolling release means that individual components can be updated as
soon as they release upstream.
I've been doing this a while,
F16 yum --releasever=17 update --bugfixes --exclude=fedora-release*
--
Regards,

Frank Murphy
UTF_8 Encoded
mike cloaked
2012-01-24 12:44:47 UTC
Permalink
Post by Frank Murphy
Post by mike cloaked
The number of problems that have been reported to the lists for yum
upgrades seems very large.  Although for any rolling release there
have been occasions where unforeseen problems have arisen the day to
day updates have been largely routine and trouble free.... hence from
what I have observed from the lists rolling releases (which of course
are generally a small percentage of the package set) are much less
problematic than one giant upgrade to all packages.   Also yum
upgrades only occur once the next system version is released whereas
rolling release means that individual components can be updated as
soon as they release upstream.
I've been doing this a while,
F16 yum --releasever=17 update --bugfixes --exclude=fedora-release*
Indeed as have many others - but although you might have never had a
problem others have. I have done a few yum upgrades too and sometimes
it worked and sometimes it needed additional investigation to get the
system into a fully working state afterwards. Occasionally I have had
significant issues - so I stayed with clean installs and configuring
from backup config files as needed in the last year or two. See my
comments in my other posts too though.
--
mike c
Michal Schmidt
2012-01-24 14:05:11 UTC
Permalink
Post by Frank Murphy
I've been doing this a while,
F16 yum --releasever=17 update --bugfixes --exclude=fedora-release*
How can the "--bugfixes" possibly work when there are no updates
metadata in Rawhide?

Michal
Frank Murphy
2012-01-24 14:31:13 UTC
Permalink
Post by Michal Schmidt
Post by Frank Murphy
I've been doing this a while,
F16 yum --releasever=17 update --bugfixes --exclude=fedora-release*
How can the "--bugfixes" possibly work when there are no updates
metadata in Rawhide?
Michal
We'll it doesn't throw an error.
So no idea.
--
Regards,

Frank Murphy
UTF_8 Encoded
Frank Murphy
2012-01-24 14:41:09 UTC
Permalink
Post by Frank Murphy
Post by Michal Schmidt
How can the "--bugfixes" possibly work when there are no updates
metadata in Rawhide?
Michal
We'll it doesn't throw an error.
So no idea.
Apologies forget paste link:
http://fpaste.org/IvtS/
--
Regards,

Frank Murphy
UTF_8 Encoded
Mark Bidewell
2012-01-24 14:51:20 UTC
Permalink
I have used Fedora, Ubuntu, and Arch. I believe the ideal is a
combination of the three
1) A pure rolling release like Arch, upgrades packages when they are
stable without regard to external impacts. The early adoption of
Python 3 in Arch broke many packages and took awhile to fix.
2) Ubuntu has 6 month releases and 2 year LTS releases. PPAs allow
upgrading of some packages without touching the core system.
3) Fedora gives rapid shipping of latest packages.

In my mind an ideal linux distro would break up the package set into:

1) User - These are packages that users want rapid access to the
latest (Examples Firefox, Libreoffice)
2) System - These are packages that better be stable and working
without external breakage before being pushed but still readily
available (Examples: X11, KDE, GNOME, XFCE, Perl, Python).
3) Core - These packages represent the base system needed to operate
these packages should move with utmost caution (Examples: kernel,
gcc, glibc, shell). A somewhat stable kernel ABI would help, but that
is not happening.

Recommended Cycles for major upgrades for each group:
1) User - As soon as possible.
2) System - 6 months.
3) Core - 12-18 months.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
Rahul Sundaram
2012-01-24 15:03:15 UTC
Permalink
Post by Mark Bidewell
1) User - As soon as possible.
2) System - 6 months.
3) Core - 12-18 months.
Problem is that, it is often the case that 1) requires updates in 2) and
sometimes even 3)

Rahul
Mark Bidewell
2012-01-24 15:24:32 UTC
Permalink
Post by Rahul Sundaram
Post by Mark Bidewell
1) User - As soon as possible.
2) System - 6 months.
3) Core - 12-18 months.
Problem is that, it is often the case that 1) requires updates in 2) and
sometimes even 3)
Rahul
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hence why I wish there was some commitment to ABI stability :-(.
However, I don't think the situation is as dire as you suggest. for
the following reasons:

1) I don't think that many changes in the user section would rely
heavily on new libraries. (Firefox 9 and Libreoffice both run fine on
Ubuntu 10.04 LTS which is almost 2 years old).
2) If a User package does require system changes the the upgrade
waits to the next system release (This is the current Fedora model).
3) If a package needed changes to all three (I can't think of an
example KVM maybe). Then a release could be cut with everything at
the latest/required versions. Interested users could upgrade, the
remainder would be brought current at the next "core" release.

The big idea behind what I propose is that package upgrades need to be
differentiated based on the potential for disruption. An upgrade to
libreoffice is less disruptive than a kernel upgrade and an upgrade to
Gnome is more disruptive than a libreoffice upgrade.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
Rahul Sundaram
2012-01-24 15:26:48 UTC
Permalink
Post by Mark Bidewell
1) I don't think that many changes in the user section would rely
heavily on new libraries. (Firefox 9 and Libreoffice both run fine on
Ubuntu 10.04 LTS which is almost 2 years old).
Only if they bundle libraries.

Rahul
Nicolas Mailhot
2012-01-24 18:07:54 UTC
Permalink
Post by Rahul Sundaram
Post by Mark Bidewell
1) User - As soon as possible.
2) System - 6 months.
3) Core - 12-18 months.
Problem is that, it is often the case that 1) requires updates in 2) and
sometimes even 3)
Actually, the biggest problem is that rawhide's core is stable and mature, and
can be used directly in a rolling release, and user parts are not, and break
all the time.

So what Mark asks for is the reverse of the current state. If we were able to
do continuous releases of desktop parts without continuous breakage, rawhide
would be pretty stable.
--
Nicolas Mailhot
Genes MailLists
2012-01-24 13:13:00 UTC
Permalink
Post by Josh Boyer
How is rawhide not a rolling release? Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
Actually it is totally unsuitable for a stable rolling release.

A rolling release, as most mean it these days, is a stable release -
with testing and development repos (rawhide is just the latter).

A key point of a rolling release is that it offers a continuous series
of smaller changes rather than 1 big change every 6 -9 months (or 2
years in case of enterprise).

Once you've installed a rolling release there are no more 'big
annoying upgrades' ... really ideal for servers and brilliant for the
desktop.

For the enterprise - many may prefer quarterly updates rather than
huge updates every few years.

Further, for those bigger changes (initd, gnome-shell whatever) - one
only has to deal with a single thing changing - which can easily be
backed out if its a problem (think systemd) - and not the compound
impact of multiple large changes.

In my view, a rolling release model is the way forward - for foss and
enterprise both.

It is the standard model for much if not most software devel in the
commercial world - as well as the linux kernel, mozilla, google chrome etc).

It makes a lot of sense ... and offers a great business opportunity on
the enterprise side as well - switching to a rolling release model for
fedora could be a really huge win.

imho of course :-

Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.

gene - user since RH3.
Henrique Junior
2012-01-24 14:03:48 UTC
Permalink
How is rawhide not a rolling release?  Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
 Actually it is totally unsuitable for a stable rolling release.
 A rolling release, as most mean it these days, is a stable release -
with testing and development repos (rawhide is just the latter).
 A key point of a rolling release is that it offers a continuous series
of smaller changes rather than 1 big change every 6 -9 months (or 2
years in case of enterprise).
 Once you've installed a rolling release there are no more 'big
annoying upgrades' ... really ideal for servers and brilliant for the
desktop.
 For the enterprise - many may prefer quarterly updates rather than
huge updates every few years.
 Further, for those bigger changes (initd, gnome-shell whatever) - one
only has to deal with a single thing changing - which can easily be
backed out if its a problem (think systemd) - and not the compound
impact of multiple large changes.
 In my view, a rolling release model is the way forward - for foss and
enterprise both.
 It is the standard model for much if not most software devel in the
commercial world - as well as the linux kernel, mozilla, google chrome etc).
 It makes a lot of sense ... and offers a great business opportunity on
the enterprise side as well - switching to a rolling release model for
fedora could be a really huge win.
 imho of course :-
 Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
 gene - user since RH3.
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
+1 on that
--
Henrique "LonelySpooky" Junior
Michal Schmidt
2012-01-24 14:08:44 UTC
Permalink
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
What the ...?

https://admin.fedoraproject.org/updates/systemd

How's that for immediately stopped being supported?

Michal
Genes MailLists
2012-01-24 14:39:19 UTC
Permalink
Post by Michal Schmidt
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
What the ...?
systemd 26 vs 37/38 ... tho you're right yes there were/are some
damage control fixes ... which is the point - in a rolling release model
things like this would (should) get the proper attention they need,
instead of moving focus on to the 'next release' ...

The 'old school' approach is/was to delay systemd (as happened in F14
as we all recall) - a rolling release would allow it to evolve in
testing until its properly ready - without the constraints of making F14
or F15 ... just allow it to grow up until it is adult enough to slide
into stable.
Rahul Sundaram
2012-01-24 14:48:57 UTC
Permalink
Post by Genes MailLists
Post by Michal Schmidt
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
What the ...?
systemd 26 vs 37/38 ... tho you're right yes there were/are some
damage control fixes ... which is the point - in a rolling release model
things like this would (should) get the proper attention they need,
instead of moving focus on to the 'next release' ...
You are ridding on thin ice here. systemd gets many many updates.
Claiming that it doesnt receive proper attention is very much
unsubstantiated. I think you should go back on this claim.


Rahul
Reindl Harald
2012-01-24 15:53:32 UTC
Permalink
Post by Rahul Sundaram
Post by Genes MailLists
Post by Michal Schmidt
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
What the ...?
systemd 26 vs 37/38 ... tho you're right yes there were/are some
damage control fixes ... which is the point - in a rolling release model
things like this would (should) get the proper attention they need,
instead of moving focus on to the 'next release' ...
You are ridding on thin ice here. systemd gets many many updates.
Claiming that it doesnt receive proper attention is very much
unsubstantiated. I think you should go back on this claim.
where are they for F15?

systemd-26-14.fc15
systemd-37-9.fc16

this is BAD because the version in F15 was a really EARLY state
services for F16 like cups rely on systemd-features that do NOT
exist in F15 - so you have no chance converting sysv to systemd
in an easy way on your F15 installation

this is NOT "receive proper attention"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/d793954b/attachment-0001.sig>
Kevin Fenzi
2012-01-24 16:01:59 UTC
Permalink
On Tue, 24 Jan 2012 16:53:32 +0100
Post by Reindl Harald
Post by Rahul Sundaram
Post by Genes MailLists
Post by Michal Schmidt
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are
there large changes as part of many releases, but lately some of
them immediately stop being supported until the 'next big
release' - which makes fedora far less reliable and desirable -
examples of this are systemd and pulse audio - there may be
others.
What the ...?
systemd 26 vs 37/38 ... tho you're right yes there were/are some
damage control fixes ... which is the point - in a rolling release
model things like this would (should) get the proper attention
they need, instead of moving focus on to the 'next release' ...
You are ridding on thin ice here. systemd gets many many updates.
Claiming that it doesnt receive proper attention is very much
unsubstantiated. I think you should go back on this claim.
where are they for F15?
systemd-26-14.fc15
systemd-37-9.fc16
this is BAD because the version in F15 was a really EARLY state
services for F16 like cups rely on systemd-features that do NOT
exist in F15 - so you have no chance converting sysv to systemd
in an easy way on your F15 installation
this is NOT "receive proper attention"
You are blindly looking at version numbers here. ;)

Take a look at the number of patches where fixes and other enhancements
have been backported to the F16/F15 packages:

https://community.dev.fedoraproject.org/packages/systemd

(Use the Fedora 16 release from the pulldown there).

The maintainer(s) are backporting those items that are safe to
backport.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/7542f850/attachment.sig>
Michal Schmidt
2012-01-24 16:07:58 UTC
Permalink
Post by Reindl Harald
Post by Rahul Sundaram
You are ridding on thin ice here. systemd gets many many updates.
Claiming that it doesnt receive proper attention is very much
unsubstantiated. I think you should go back on this claim.
where are they for F15?
systemd-26-14.fc15
systemd-37-9.fc16
this is BAD because the version in F15 was a really EARLY state
services for F16 like cups rely on systemd-features that do NOT
exist in F15 - so you have no chance converting sysv to systemd
in an easy way on your F15 installation
So you keep saying in every discussion where systemd is mentioned that
F15 was broken because most services were still SysV.
I disagree with that opinion. One of systemd's features is a pretty good
level of SysV compatibility.
If there's anything wrong with cups in F15, it should be possible to fix
it within F15's feature set.
I really don't understand the mania to produce an F15 system without
SysV services. You're only bringing the problems upon yourself.

Michal
Reindl Harald
2012-01-24 16:17:40 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
this is BAD because the version in F15 was a really EARLY state
services for F16 like cups rely on systemd-features that do NOT
exist in F15 - so you have no chance converting sysv to systemd
in an easy way on your F15 installation
I disagree with that opinion. One of systemd's features is a pretty
good level of SysV compatibility. If there's anything wrong with cups
in F15, it should be possible to fix it within F15's feature set.
I really don't understand the mania to produce an F15 system without
SysV services. You're only bringing the problems upon yourself.
you definition of a clean system is not mine

when i see that services which was not converted to systemd
needs features which were not available with the systemd
of F15 this is a clear sign that systemd was NOT ready for
a GA release

so updates should make it ready for GA

how do you imagine that even maintainers could have
converted services for the F15 release with a
non-finished systemd-version?

in my opinion if a core component is changed it must
not be put in GA before it is ready or if it was too
early it should been fixed in all points of view instead
forcing users "take the next dist-upgrade and look what
components we broke there"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/3d3d3fab/attachment.sig>
Johannes Lips
2012-01-24 16:21:45 UTC
Permalink
YAWN!
Post by Reindl Harald
Post by Michal Schmidt
Post by Reindl Harald
this is BAD because the version in F15 was a really EARLY state
services for F16 like cups rely on systemd-features that do NOT
exist in F15 - so you have no chance converting sysv to systemd
in an easy way on your F15 installation
I disagree with that opinion. One of systemd's features is a pretty
good level of SysV compatibility. If there's anything wrong with cups
in F15, it should be possible to fix it within F15's feature set.
I really don't understand the mania to produce an F15 system without
SysV services. You're only bringing the problems upon yourself.
you definition of a clean system is not mine
when i see that services which was not converted to systemd
needs features which were not available with the systemd
of F15 this is a clear sign that systemd was NOT ready for
a GA release
so updates should make it ready for GA
how do you imagine that even maintainers could have
converted services for the F15 release with a
non-finished systemd-version?
in my opinion if a core component is changed it must
not be put in GA before it is ready or if it was too
early it should been fixed in all points of view instead
forcing users "take the next dist-upgrade and look what
components we broke there"
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/0a71ca45/attachment.html>
Frank Murphy
2012-01-24 16:25:12 UTC
Permalink
YAWN!
Please don't, I've got Narcolepsy.
--
Regards,

Frank Murphy
UTF_8 Encoded
Michal Schmidt
2012-01-24 16:37:52 UTC
Permalink
Post by Reindl Harald
when i see that services which was not converted to systemd
needs features which were not available with the systemd
of F15 this is a clear sign that systemd was NOT ready for
a GA release
That missing feature is "PathExistsGlob=", isn't it?
So the solution is easy - just have cups.service start the classical
way: by pulling it into the default target.
Cups worked without path-based activation when it was a SysV service and
it can work just the same as a native service.
Post by Reindl Harald
so updates should make it ready for GA
how do you imagine that even maintainers could have
converted services for the F15 release with a
non-finished systemd-version?
I am amazed at the sophistry of the argument.

We sometimes add new features to systemd that service writers might find
convenient to use in their unit files. I guess that does make systemd
"non-finished" when interpreted literally.
What follows from that when it comes to suitability for a release?
Absolutely nothing.

Michal
Reindl Harald
2012-01-24 17:12:24 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
when i see that services which was not converted to systemd
needs features which were not available with the systemd
of F15 this is a clear sign that systemd was NOT ready for
a GA release
That missing feature is "PathExistsGlob=", isn't it?
So the solution is easy - just have cups.service start the classical way: by pulling it into the default target.
Cups worked without path-based activation when it was a SysV service and it can work just the same as a native
service.
well, you can not do a simple "rpmbuild --rebuild cups.src.rpm.fc16"
it makes life harder
Post by Michal Schmidt
Post by Reindl Harald
so updates should make it ready for GA
how do you imagine that even maintainers could have
converted services for the F15 release with a
non-finished systemd-version?
I am amazed at the sophistry of the argument.
We sometimes add new features to systemd that service writers might find convenient to
use in their unit files. I guess that does make systemd "non-finished" when
interpreted literally.
yes because anybody who does not upgrade on the first release
day for very good reasons has to live with missing options
Post by Michal Schmidt
What follows from that when it comes to suitability for a release?
Absolutely nothing.
if F15 would get the new features all would be fine but it does not, it
was a shot in the dark with only a few services converted and nothing
changes until the next dist-upgrade

after all the troubles i had only with mysqld based services and
F15 you should understand that i hestitate to make a F16 upgrade
where as example GRUB2 is introduced without a automatic transition
resulting in grubby always whining about a missing template (whatever
that means) on each kernel update, no idea how a "grub-install /dev/sda-/dev/sdd"
for systems booting form RAID1 devices should be done and such questions
which needs time to find out and test

in my opinion if core-subsystems are rewritten they should get updates
on a regular base at least for the initial release and not stay as
they where



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/8d31b616/attachment.sig>
Michal Schmidt
2012-01-24 15:30:24 UTC
Permalink
Post by Genes MailLists
Post by Michal Schmidt
Post by Genes MailLists
Fedora suffers an additional problem it seems - not only are there
large changes as part of many releases, but lately some of them
immediately stop being supported until the 'next big release' - which
makes fedora far less reliable and desirable - examples of this are
systemd and pulse audio - there may be others.
What the ...?
systemd 26 vs 37/38 ... tho you're right yes there were/are some
damage control fixes ... which is the point - in a rolling release model
things like this would (should) get the proper attention they need,
instead of moving focus on to the 'next release' ...
I personally would not mind a rolling Fedora release.

But we are not currently following a rolling release model, so your
criticism of systemd maintenance on stable Fedora branches (what you
called "an additional problem") is invalid. We put in a lot of bugfixes
from upstream. We follow the Fedora Updates Policy and avoid radical
changes.

Michal
Darryl L. Pierce
2012-01-24 14:16:08 UTC
Permalink
Post by Josh Boyer
Post by mike cloaked
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
Is there a possibility that not moving to rolling release could
ultimately damage Fedora in the future as other distributions increase
their support base?
How is rawhide not a rolling release? Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
I would say Rawhide isn't a rolling release due to it being considered
unstable packages; i.e., ones that have not been fully vetted. It's
analogous to Debian's Sid.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/87d5fda2/attachment.sig>
Till Maas
2012-01-24 21:47:19 UTC
Permalink
Post by Josh Boyer
Or perhaps better asked, what
about rawhide makes it
unsuitable for use as a rolling Fedora release?
The rpm packages in Rawhide are not signed.

Regards
Till
Richard W.M. Jones
2012-01-24 12:24:42 UTC
Permalink
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
I doubt your claims here.

Fedora already has a perfectly good rolling release. It's called
Rawhide, and I run it on my laptop. I'd be nuts to run it on a
server.

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
Andrew Price
2012-01-24 12:54:13 UTC
Permalink
Post by Richard W.M. Jones
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
I doubt your claims here.
Fedora already has a perfectly good rolling release. It's called
Rawhide, and I run it on my laptop. I'd be nuts to run it on a
server.
I run Debian Testing (a rolling "release") on my desktop machine. I
wouldn't recommend it for servers either, but I find it roughly as
stable as Fedora releases. Why? Because the equivalent of Rawhide in
Debian is Debian Unstable and packages have to be critical-bug-free in
Unstable for a time before they graduate to Testing.

If there was a rolling repository like this sitting between Rawhide and
Fedora N+1 then I'd most certainly use it. As it is, I'm quite happy
using Fedora 16 on my laptop until 17 is released.

Andy
Genes MailLists
2012-01-24 12:56:54 UTC
Permalink
Post by Richard W.M. Jones
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
I doubt your claims here.
Fedora already has a perfectly good rolling release. It's called
Rawhide, and I run it on my laptop. I'd be nuts to run it on a
server.
exactly - rawhide is not a rolling release as everyone uses the phrase.


A rolling release typically has 3 repos - stable, testing and
development.

rawhide is really on the 'devel' part.
Ralf Corsepius
2012-01-24 13:12:53 UTC
Permalink
Post by Richard W.M. Jones
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
I doubt your claims here.
Fedora already has a perfectly good rolling release. It's called
Rawhide, and I run it on my laptop.
Not quite. Rawhide is RH's and Fedora's rough, uncooked, unstable and
experimental spear-head.

This has nothing in common with a "stable" and "properly packaged"
rolling release.

Ralf
Jon Ciesla
2012-01-24 13:18:59 UTC
Permalink
Post by Richard W.M. Jones
Post by mike cloaked
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version.  For servers there
would be huge advantages in management of systems.
I doubt your claims here.
Fedora already has a perfectly good rolling release.  It's called
Rawhide, and I run it on my laptop.  I'd be nuts to run it on a
server.
(whistles quietly to self, looks around, goes about business)
Post by Richard W.M. Jones
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love

-d. bowie
Nathaniel McCallum
2012-01-24 14:47:45 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
http://cut.debian.net/
http://en.opensuse.org/Portal:Tumbleweed
https://wiki.archlinux.org/index.php/Arch_Linux
Gentoo is also essentially a rolling release distribution.
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version. For servers there
would be huge advantages in management of systems.
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
Is there a possibility that not moving to rolling release could
ultimately damage Fedora in the future as other distributions increase
their support base?
I thought this might lead to a useful discussion and this post is not
supposed to be a flame bait but a genuine question that is potentially
quite fundamental to the future of Fedora. Applying innovative and
careful thought to this question might be helpful to the Fedora
project as a whole.
+1

The structure I'd like to see is: rawhide -> testing -> stable and then
every 6 months release a hardened fork off of stable as a static release
(Fedora N). If you want to run the stable or testing branches you install
the latest Fedora N release and then yum upgrade to stable. This seems to
me like not a lot of work besides the new policy that would obviously
govern packagers and how they merge to the branches. I also think this
would provide a marked benefit of stability to the static releases.

Perhaps someone can fill us in on what work would need to be done to make
this happen?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/ac2e400f/attachment.html>
Przemek Klosowski
2012-01-24 19:13:30 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
I have some systems that were upgraded across multiple Fedora releases,
some strictly incrementally and some by skipping intermediate releases,
so I am attracted to the concept of a rolling release. Among other
things, it would solve the problem of officially unsupported releases,
thus making it easier to deploy Fedora in regulated environments (PCI,
FISMA, etc). I was always able to make extended Fedora upgrades work,
but I encountered some tricky problems that make me wonder if a rolling
update can be made smooth and reliable.

To me, the best of both worlds would be an upgrade path to a
long-term-supported configuration like RHEL or Centos. This way, users
could track Fedora developments if they wish, but also retire systems
into a long-term-supported configuration, after the Fedora update
support ends. It would be a reasonable compromise between the relatively
short Fedora support cycle and the stagnation of the stable systems; a
'rolling into a rut' rather than 'rolling forever' release.

Here's what I think is the problem with rolling releases: they imply
preserving a running configuration. At the same time, the relevant
subsystems change, and the migration of the old configuration to the new
environment can go in each one of those three ways:

- everything works perfectly in the updated subsystem

- configuration can be ported and made to work, but is suboptimal

- old stuff doesn't work, new setup is required

I think that the second case is not uncommon, especially in heavily
customized systems, such as servers. A rolling release looks attractive
and simple, but an accumulation of such suboptimal steps could result
instead in crufty, fragile, and hard to support systems.

In other words, an occasional reinstall from scratch may be the price
for the full benefits of Fedora's intensive development.


As a separate issue affecting developers rather than users, the current
Fedora release workflow has the natural rhythm that the rolling release
might lack.
Kevin Kofler
2012-01-24 19:59:43 UTC
Permalink
Post by mike cloaked
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
No. We've had this discussion many times. It just doesn't work.

There are changes like KDE 4 or GNOME 3 which can't just be pushed as an
update in a smooth way. A rolling release will always have such choking
points.

Where we can get to is "semi-rolling", i.e. push version upgrades as updates
to stable releases wherever safe, but not the disruptive changes. In fact,
that's what we did before the new stable update policies which I still
believe are NOT what the majority wants and need to be repealed (and be
replaced by a policy which ensures that packages will be consistently
upgraded, without the "I maintain package XYZ and I don't believe in version
upgrades for stable releases, so there will be none" nonsense). Want the
disruptive changes? Then yum upgrade to the latest release. Otherwise you
only get the safe ones.

But a fully rolling release just cannot work (and this is also why all those
"just use Rawhide if you want the latest", "usable Rawhide" etc. suggestions
are fundamentally flawed). Yes, there are distros doing this, but they all
have one thing in common: doing a migration like the KDE 4 migration is a
big PITA in them.

Kevin Kofler
Genes MailLists
2012-01-24 20:11:03 UTC
Permalink
Post by Kevin Kofler
But a fully rolling release just cannot work (and this is also why all those
"just use Rawhide if you want the latest", "usable Rawhide" etc. suggestions
are fundamentally flawed). Yes, there are distros doing this, but they all
have one thing in common: doing a migration like the KDE 4 migration is a
big PITA in them.
Moving any large change has challenges - whether periodic or rolling.

In that sense, they are no different - both can be a PITA.

However, in a rolling model you have the advantage of it being the
-only- change you need to do .. which is far less an issue than the
compound change impact .. and many more people can explore the testing
repo with only that one single change, which allows kinks to be worked
out sooner.

I know you've held this view a while however - when you guys created
kde-redhat to allow fedora stable users to explore the 'new kde stuff' -
that is exactly how a rolling release works. You've actually been doing
it already .. .. :-)

Now if Adam W. would just step up again and offer to drive this
forward .. Adam?
mike cloaked
2012-01-24 20:40:13 UTC
Permalink
 Moving any large change has challenges - whether periodic or rolling.
 In that sense, they are no different - both can be a PITA.
 However, in a rolling model you have the advantage of it being the
-only- change you need to do .. which is far less an issue than the
Indeed - also it is also the case that whenever any really significant
change is mooted in any complex system or facility that the first
response is often for everyone to find all the reasons that they can
think of for not making any change since making change means work and
it is scary. However there are some people who will think carefully
about any proposal and see if the work necessary could lead to a
better overall model for the system.

There have been a few who have expressed some support for the idea of
rolling release - after all in terms of overall work consider the
global effort - if there were rawhide, testing and stable repos (as
now) but the idea of rawhide was to generate new packages that would
be put together to make install isos (or live isos), which could
install new systems as clean installs, and the testing repo was QA
tested for updating new installs, as well as stable previously
installed systems once the bugs were worked through for those two
scenarios then packages could be pushed to stable as tested for both
updating new installed systems and people already running stable.

That way once installed there is no need to maintain and test updates
specifically for the current release. As an overall workload would
this actually be any more effort than the constant stream of testing
for the "two" current releases - as an overall picture?

Of course anyone could choose to clean install a really old system
that had problems but in general updating small chunks of packages
would be very desirable for users.
--
mike c
Kevin Kofler
2012-01-24 22:00:56 UTC
Permalink
Post by mike cloaked
That way once installed there is no need to maintain and test updates
specifically for the current release. As an overall workload would
this actually be any more effort than the constant stream of testing
for the "two" current releases - as an overall picture?
Of course it's less work for us if we only do Rawhide, but then that leaves
our users with nothing usable for production machines at all!

This is a no go.

Any rolling model which is suitable for production machines would be
completely unsupportable, because it'd mean you'd have to be able to
individually opt out of every single migration, leading to an exponential,
and thus both untestable and unmaintainable, explosion of possible setups.

There is just no alternative to doing releases for the disruptive changes.

Kevin Kofler
Kevin Kofler
2012-01-24 21:08:58 UTC
Permalink
Post by Genes MailLists
Moving any large change has challenges - whether periodic or rolling.
In that sense, they are no different - both can be a PITA.
However, in a rolling model you have the advantage of it being the
-only- change you need to do .. which is far less an issue than the
compound change impact .. and many more people can explore the testing
repo with only that one single change, which allows kinks to be worked
out sooner.
Sure, it will be the only change that day, if you're lucky (there's no
guarantee there won't be multiple changes happening to land at the same
time), but in exchange, you can be hit with such a change at any moment,
including when you least expect it (and might not have time to deal with the
issues that arise), and your only option for escaping the change is not
updating at all (and not getting security fixes). You also get hit with such
changes many times a year rather than twice (or even once if you skip every
other release, as allowed by the Fedora release cycle). I don't think that's
a win at all.
Post by Genes MailLists
I know you've held this view a while however - when you guys created
kde-redhat to allow fedora stable users to explore the 'new kde stuff' -
that is exactly how a rolling release works. You've actually been doing
it already .. .. :-)
Not really
 Yes, kde-unstable is like a rolling release, but of the KDE
parts only. The whole reason why you'd run kde-unstable rather than Rawhide
is to NOT get the disruptive changes in all the other components (kernel,
X.Org X11 etc.), while still testing the very latest KDE SC. And even
considering that, I don't recommend running kde-unstable on a production
machine at all.

kde-stable and kde-testing are actually NOT "rolling release" repos, but at
most "semi-rolling release" as I explained in my mail, i.e. they contain
only changes which are safe to use as updates. (And these days, we actually
try to only put things there which are pending for official updates.) For
F15, we also provide a kde47 repository to provide KDE SC 4.7 as an optional
upgrade, exactly so you didn't have to use all of kde-unstable (or even
Rawhide) to get 4.7 before F16. That's a targeted upgrade of a specific
component in an optional repository (where in fact we discussed for quite
some time whether it wouldn't have been safe to push as an official stable
update, i.e. we provided it separately from Rawhide/kde-unstable because it
was in fact NOT that disruptive) and very far from a rolling release of the
entire distribution with all the roadbumps.
Post by Genes MailLists
Now if Adam W. would just step up again and offer to drive this
forward .. Adam?
I don't think it makes sense for an individual to drive this forward without
any sort of consensus.

Kevin Kofler
Frank Murphy
2012-01-24 21:28:19 UTC
Permalink
Post by Kevin Kofler
I don't think it makes sense for an individual to drive this forward without
any sort of consensus.
Kevin Kofler
I disagree, in a manner.
Not necessarily drive forward.
But at least have a presentaion ready.
With some facts, some analysis, some conclusions.

1: Hardware physical\virtual requirements.
2: Infra, expansion of
3: Talk to the other distros.

There is more I could say on this, but it's late.
--
Regards,

Frank Murphy
UTF_8 Encoded
mike cloaked
2012-01-24 21:41:10 UTC
Permalink
Post by Frank Murphy
Post by Kevin Kofler
I don't think it makes sense for an individual to drive this forward without
any sort of consensus.
        Kevin Kofler
I disagree, in a manner.
Not necessarily drive forward.
But at least have a presentaion ready.
With some facts, some analysis, some conclusions.
1: Hardware physical\virtual requirements.
2: Infra, expansion of
3: Talk to the other distros.
There is more I could say on this, but it's late.
Indeed - however one comment from me before the end of my evening - it
is not as if this idea is being created out of thin air - there are
rolling releases already in existence - and working - just not in
Fedora.

Good night all.
--
mike c
mike cloaked
2012-01-24 20:13:05 UTC
Permalink
Post by Kevin Kofler
Post by mike cloaked
Is there any support at all within the development community for a
rolling release version of Fedora (and possibly ulitimately Redhat)?
No. We've had this discussion many times. It just doesn't work.
There are changes like KDE 4 or GNOME 3 which can't just be pushed as an
update in a smooth way. A rolling release will always have such choking
points.
So how did Arch Linux cope with that particular set of changes? I
suppose Arch Linux collapsed never to recover? I think not!
Post by Kevin Kofler
Where we can get to is "semi-rolling", i.e. push version upgrades as updates
to stable releases wherever safe, but not the disruptive changes.
That is actually more like rolling release- except that there is no
EOL in a rolling release model! Periodically there are new install or
live isos but an installed system just keeps getting new stufff!

In fact,
Post by Kevin Kofler
that's what we did before the new stable update policies which I still
believe are NOT what the majority wants and need to be repealed (and be
replaced by a policy which ensures that packages will be consistently
upgraded, without the "I maintain package XYZ and I don't believe in version
upgrades for stable releases, so there will be none" nonsense). Want the
disruptive changes? Then yum upgrade to the latest release. Otherwise you
only get the safe ones.
Yup big updates that may sometimes need manual intervention to change
configs - an example is dovecot when it changed to v2 - the configs
changed. Not insurmountable - but at least without changing
everything else at the same time it is a lot easier to deal with,
surely?
Post by Kevin Kofler
But a fully rolling release just cannot work (and this is also why all those
"just use Rawhide if you want the latest", "usable Rawhide" etc. suggestions
are fundamentally flawed). Yes, there are distros doing this, but they all
have one thing in common: doing a migration like the KDE 4 migration is a
big PITA in them.
Again - how on earth did Arch Linux survive it - and did the arch
users desert that distro in large numbers as a result? I don't think
so.
--
mike c
David
2012-01-24 20:52:57 UTC
Permalink
On 1/24/2012 3:13 PM, mike cloaked wrote:

<Big snip>
Post by mike cloaked
Again - how on earth did Arch Linux survive it - and did the arch
users desert that distro in large numbers as a result? I don't think
so.
A question please? Two related ones actually.

What are you going to name your rolling Linux release? And when can we
expect to see it?

:-) <<< notice this.
--
David

"May your road lead you to warm sands."
mike cloaked
2012-01-24 21:02:08 UTC
Permalink
Post by David
A question please? Two related ones actually.
What are you going to name your rolling Linux release? And when can we
expect to see it?
:-)   <<< notice this.
Of course the decision about a name would be a really huge discussion!
But if there was a "Fedora Stable Leader" or anything vaguely
equivalent then I would be very interested in following by being a
dedicated user.

I couldn't possibly answer the second question but I would be
surprised if, given the will to work on it, starting after the next
release, if a year later a first shot could not be up and working.
After all from a rawhide designed to work to such a new model, working
towards the next release say after f17 which would not be very much
different to the existing rawhide timescale, and then maintaining a
test regime to support packages for a newly installed system from the
latest rawhide snapshot at the release point, plus testing the
existing two current releases at the same point with a view to moving
to rolling release doesn't seem beyond being reasonable - though of
course there will be a variety of opinions on that issue I am quite
sure!
--
mike c
Frank Murphy
2012-01-24 21:06:43 UTC
Permalink
Post by David
A question please? Two related ones actually.
What are you going to name your rolling Linux release? And when can we
expect to see it?
:-)<<< notice this.
Rooling rooling rooling Rawhiiiide

):)(
--
Regards,

Frank Murphy
UTF_8 Encoded
Rich Megginson
2012-01-24 21:12:21 UTC
Permalink
Post by Frank Murphy
Post by David
A question please? Two related ones actually.
What are you going to name your rolling Linux release? And when can we
expect to see it?
:-)<<< notice this.
Rooling rooling rooling Rawhiiiide
+1
/me hands Frank a whip for crackin'
Post by Frank Murphy
):)(
Jon Ciesla
2012-01-24 21:20:24 UTC
Permalink
Post by Rich Megginson
Post by Frank Murphy
Post by David
A question please? Two related ones actually.
What are you going to name your rolling Linux release? And when can we
expect to see it?
:-)<<<  notice this.
Rooling rooling rooling Rawhiiiide
+1
/me hands Frank a whip for crackin'
Orange whip? Orange whip? Three orange whips!

-J
Post by Rich Megginson
Post by Frank Murphy
):)(
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love

-d. bowie
mike cloaked
2012-01-24 21:16:07 UTC
Permalink
Post by Frank Murphy
Post by David
A question please? Two related ones actually.
What are you going to name your rolling Linux release? And when can we
expect to see it?
:-)<<<  notice this.
Rooling rooling rooling Rawhiiiide
Sung no doubt in that deep Johnny Cash slow drawl - hah!
--
mike c
Jef Spaleta
2012-01-24 20:59:32 UTC
Permalink
So how did Arch Linux cope with that particular set of changes?  I
suppose Arch Linux collapsed never to recover?  I think not!
It would behoove the argument you are making if you could write up the
summary of how Arch handles technology shifts for us to review,
instead of challenging us to look it up ourselves. You've brought up
Arch as an example, its in your best interest to educate the rest of
us about how they operate as part of making your argument stick. Your
challenge as a rhetorical device doesn't work when the people you are
challenging do not yet have a vested interest in making the change.
You do, and thus, and your interests as an advocate of change are best
served by walking the rest of us through how Arch does disruptive
change management in their release process.

-jef
mike cloaked
2012-01-24 21:14:08 UTC
Permalink
Post by Jef Spaleta
So how did Arch Linux cope with that particular set of changes?  I
suppose Arch Linux collapsed never to recover?  I think not!
It would behoove the argument you are making if you could write up the
summary of how Arch handles technology shifts for us to review,
instead of challenging us to look it up ourselves.  You've brought up
Arch as an example, its in your best interest to educate the rest of
us about how they operate as part of making your argument stick.  Your
challenge as a rhetorical device doesn't work when the people you are
challenging do not yet have a vested interest in making the change.
You do, and thus, and your interests as an advocate of change are best
served by walking the rest of us through how Arch does disruptive
change management in their release process.
Arch has an extensive wiki and a lot of very helpful forums including
a valuable announce forum

https://wiki.archlinux.org/index.php/Main_Page
https://bbs.archlinux.org/
https://bbs.archlinux.org/viewforum.php?id=24

When there are disruptive changes they try to announce any manual
intervention required once a new package set of this kind is updated -
for example a recent announcement was for the (unstable) KDE 4.8 which
has an extensive discussion about what might be needed to watch out
for as well as the opportunity for users to test it - when it is
considered stable enough it will go out to stable with any suitable
notes for what users will have to change manually after upgrading that
package set.

Another example is the announcement and ensuing discussion when
Gnome3 went to stable:
https://bbs.archlinux.org/viewtopic.php?id=117876

There appears to be quite extensive and helpful information available
for users when there are major package updates - of course there may
be wrinkles and problems occasionally - but as has been said before in
this thread dealing with the issues when updating a single major
package upgrade is much easier to deal with than upgrading the entire
system with potentially several major upgrades as part of a major
overhaul.
--
mike c
Kevin Kofler
2012-01-24 22:12:45 UTC
Permalink
Post by mike cloaked
Arch has an extensive wiki and a lot of very helpful forums including
a valuable announce forum
https://wiki.archlinux.org/index.php/Main_Page
https://bbs.archlinux.org/
https://bbs.archlinux.org/viewforum.php?id=24
If you like what Arch is doing so much, why don't you just go and use Arch?
Why should we become another Arch?
Post by mike cloaked
When there are disruptive changes they try to announce any manual
intervention required once a new package set of this kind is updated -
for example a recent announcement was for the (unstable) KDE 4.8 which
has an extensive discussion about what might be needed to watch out
for as well as the opportunity for users to test it - when it is
considered stable enough it will go out to stable with any suitable
notes for what users will have to change manually after upgrading that
package set.
It's not acceptable for an update, as opposed to a distribution upgrade, to
require ANY kind of manual intervention, and this is exactly where rolling
release models automatically fail.

FWIW, an upgrade to KDE SC 4.8 (from 4.7) should just work with no manual
intervention at all. We know about 2 issues with configuration migration,
but we consider them bugs and we're working on getting them fixed.
Post by mike cloaked
Another example is the announcement and ensuing discussion when
https://bbs.archlinux.org/viewtopic.php?id=117876
Ouch! I'm not a GNOME user, but if I were, I most definitely wouldn't want
GNOME 3 forced onto me overnight! That's a great way to lose users. There
are already enough complaints about how Fedora 15 is not carrying GNOME 2
anymore, imagine if you installed Fedora 14 (or a hypothetical Fedora
Rolling Release Installer of some date close to the actual F14 release) and
one day, your routine security and bugfix updates include GNOME 3! WTF?!
That is just totally unacceptable. Fedora gave you 7 months to either make
the switch (on YOUR schedule, not Fedora's) or look for alternatives.
Post by mike cloaked
There appears to be quite extensive and helpful information available
for users when there are major package updates - of course there may
be wrinkles and problems occasionally
Indeed. That's exactly why I would NEVER use Arch on a production machine
(and yes, I consider both my desktop and my notebook to be production
machines; not only servers are production).
Post by mike cloaked
but as has been said before in this thread dealing with the issues when
updating a single major package upgrade is much easier to deal with than
upgrading the entire system with potentially several major upgrades as
part of a major overhaul.
Nonsense. That claim has already been debunked. See my other mails in this
thread.

Kevin Kofler
Kevin Kofler
2012-01-24 21:39:44 UTC
Permalink
Post by mike cloaked
So how did Arch Linux cope with that particular set of changes? I
suppose Arch Linux collapsed never to recover? I think not!
There are 2 ways rolling release distros handle this kind of transition:

a) They just push it. That leaves you with e.g. your desktop being upgraded
from KDE 3 to KDE 4 overnight! A very nasty surprise, considering that some
reconfiguration is required for the workspace, and that some applications
got rewritten with feature regressions. IMHO such a change is totally
unsuitable to be pushed as a mandatory update.

b) They push it with a new name and force you to migrate by hand. This sucks
in several ways:
* The user has to follow a migration manual to manually replace the old
packages with the new ones.
* Either the old and new versions conflict with each other, which is not a
nice packaging practice (and makes upgrading more difficult for the user),
or they are parallel-installable, which usually implies that migration of
configuration settings is manual, too.
* The developers have to maintain both the old and new version in parallel
for quite some time, and application packagers depending on the changed
lower-level package have to support both setups, usually in the SAME package
(which is a nightmare, compared to being able to have separate branches for
the old and new setup like the Fedora 8 and 9 branches in our case), or also
duplicate their package into old and new version, with the same issues.
* The users ultimately end up with an unsupported configuration (when the
developers finally discontinue the old version) if they don't migrate
manually. So this has the same drawbacks as a release-based model, except
that (i) you have to read and follow a page of instructions to get the new
packages for a rolling release distro using approach b) instead of just
upgrading to the new release and (ii) the EOL for the old packages is
usually much less predictable than the EOL for Fedora releases.
Post by mike cloaked
Post by Kevin Kofler
Where we can get to is "semi-rolling", i.e. push version upgrades as
updates to stable releases wherever safe, but not the disruptive changes.
That is actually more like rolling release- except that there is no
EOL in a rolling release model! Periodically there are new install or
live isos but an installed system just keeps getting new stufff!
But that includes new stuff which BREAKS things! The point of the semi-
rolling model is that it does NOT include the stuff which breaks things.
Post by mike cloaked
In fact,
Post by Kevin Kofler
that's what we did before the new stable update policies which I still
believe are NOT what the majority wants and need to be repealed (and be
replaced by a policy which ensures that packages will be consistently
upgraded, without the "I maintain package XYZ and I don't believe in
version upgrades for stable releases, so there will be none" nonsense).
Want the disruptive changes? Then yum upgrade to the latest release.
Otherwise you only get the safe ones.
Yup big updates that may sometimes need manual intervention to change
configs - an example is dovecot when it changed to v2 - the configs
changed. Not insurmountable - but at least without changing
everything else at the same time it is a lot easier to deal with,
surely?
No, quite the opposite (because it means you get bothered with such changes
many times, at potentially inappropriate times, with no way to opt out), see
my reply to Gene ("Genes MailLists").
Post by mike cloaked
Post by Kevin Kofler
But a fully rolling release just cannot work (and this is also why all
those "just use Rawhide if you want the latest", "usable Rawhide" etc.
suggestions are fundamentally flawed). Yes, there are distros doing this,
but they all have one thing in common: doing a migration like the KDE 4
migration is a big PITA in them.
Again - how on earth did Arch Linux survive it
In a suboptimal way.
Post by mike cloaked
and did the arch users desert that distro in large numbers as a result?
I'm sure some of them did (and moved to release-based distros, which all
handled the transition sanely :-) ), the remaining ones are probably used to
stuff being broken, just like Rawhide users. That doesn't mean it's a model
which works for production machines.

Kevin Kofler
Bryan Quigley
2012-01-24 22:32:27 UTC
Permalink
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120124/5fbb804e/attachment.html>
Kevin Kofler
2012-01-24 23:40:43 UTC
Permalink
Post by Bryan Quigley
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
David Tardon
2012-01-25 07:50:57 UTC
Permalink
Post by Bryan Quigley
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.
Bryan Quigley
2012-01-26 01:22:44 UTC
Permalink
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?
Post by David Tardon
Post by Bryan Quigley
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 at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rahul Sundaram
2012-01-26 02:02:00 UTC
Permalink
Post by Bryan Quigley
Oh, then I guess I would like to see LibreOffice be a rolling
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
Bryan Quigley
2012-01-26 02:17:46 UTC
Permalink
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
Post by Rahul Sundaram
Post by Bryan Quigley
Oh, then I guess I would like to see LibreOffice be a rolling
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 at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rahul Sundaram
2012-01-26 02:56:19 UTC
Permalink
Post by Bryan Quigley
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
Josh Boyer
2012-01-26 03:01:51 UTC
Permalink
Post by Bryan Quigley
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
Genes MailLists
2012-01-26 03:46:42 UTC
Permalink
Post by Josh Boyer
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.
...
Post by Josh Boyer
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 ...
Scott Schmit
2012-01-26 05:22:28 UTC
Permalink
Post by Genes MailLists
Post by Josh Boyer
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.
...
Post by Josh Boyer
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4138 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120126/257c9eb9/attachment.bin>
Bruno Wolff III
2012-01-26 17:09:33 UTC
Permalink
On Thu, Jan 26, 2012 at 00:22:28 -0500,
Post by Scott Schmit
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.
Jef Spaleta
2012-01-26 17:39:24 UTC
Permalink
Post by Bruno Wolff III
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
drago01
2012-01-25 08:49:48 UTC
Permalink
Post by Bryan Quigley
LibreOffice
Not true.
drago01
2012-01-25 08:50:35 UTC
Permalink
Post by drago01
Post by Bryan Quigley
LibreOffice
Not true.
Oh David already said that ... should probably read the whole thread
before replying.
Rahul Sundaram
2012-01-25 01:30:31 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
http://cut.debian.net/
This is just a proposal. Wont happen.
Post by mike cloaked
http://en.opensuse.org/Portal:Tumbleweed
Seems to be not actively adopted
Post by mike cloaked
https://wiki.archlinux.org/index.php/Arch_Linux
This is only distro that gained any traction with this model
Post by mike cloaked
Gentoo is also essentially a rolling release distribution.
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version.
I dont think there is a massive user base waiting for a rolling release
really. Rolling release automatically implies a level of disruption
periodically everytime a major component is bumped up. Esp for binary
distros, this isn't that great a user experience. I would participate in
such a effort but I don't buy the idea of this as a trend

Rahul
Nathanael Noblet
2012-01-25 04:47:09 UTC
Permalink
Post by Rahul Sundaram
I dont think there is a massive user base waiting for a rolling release
really. Rolling release automatically implies a level of disruption
periodically everytime a major component is bumped up. Esp for binary
distros, this isn't that great a user experience. I would participate in
such a effort but I don't buy the idea of this as a trend
I'd be interested in a rolling release iff updates weren't disruptive.
Considering each release usually comes with *some* issues. Sometimes
regular updates has issues (for example eclipse updates regularly causes
me issues - no hard feelings). However if that happened regularly as the
release rolled on... I'd be finding an alternative. I like to choose
when to upgrade because I know when my schedule matches.

So far I've seen lots of discussion about can we do it, but no proposal
nor any real set of why it would be better. Does it reduce packaging
work? Does it do X Y Z? Why would I *want* a rolling release?
seth vidal
2012-01-25 05:05:23 UTC
Permalink
On Tue, 24 Jan 2012 21:47:09 -0700
Post by Nathanael Noblet
Post by Rahul Sundaram
I dont think there is a massive user base waiting for a rolling
release really. Rolling release automatically implies a level of
disruption periodically everytime a major component is bumped up.
Esp for binary distros, this isn't that great a user experience. I
would participate in such a effort but I don't buy the idea of this
as a trend
I'd be interested in a rolling release iff updates weren't
disruptive. Considering each release usually comes with *some*
issues. Sometimes regular updates has issues (for example eclipse
updates regularly causes me issues - no hard feelings). However if
that happened regularly as the release rolled on... I'd be finding an
alternative. I like to choose when to upgrade because I know when my
schedule matches.
So far I've seen lots of discussion about can we do it, but no
proposal nor any real set of why it would be better. Does it reduce
packaging work? Does it do X Y Z? Why would I *want* a rolling
release?
You want a rolling release distribution where updates are non
disruptive and go on for a long time? Can I suggest you call a red
hat sales representative b/c you're describe rhel. :)

-sv
Greg
2012-01-25 05:07:58 UTC
Permalink
Post by Nathanael Noblet
I'd be interested in a rolling release iff updates weren't disruptive.
Considering each release usually comes with *some* issues. Sometimes
regular updates has issues (for example eclipse updates regularly
causes me issues - no hard feelings). However if that happened
regularly as the release rolled on... I'd be finding an alternative. I
like to choose when to upgrade because I know when my schedule matches.
So far I've seen lots of discussion about can we do it, but no
proposal nor any real set of why it would be better. Does it reduce
packaging work? Does it do X Y Z? Why would I *want* a rolling release?
or you can use CentOS or Scientific Linux for this. or Debian or Ubuntu LTS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120125/228a0ba9/attachment.html>
Jef Spaleta
2012-01-25 17:36:53 UTC
Permalink
So far I've seen lots of discussion about can we do it, but no proposal nor
any real set of why it would be better. Does it reduce packaging work? Does
it do X Y Z? Why would I *want* a rolling release?
So far I'm not thrilled with what I've read in the historic Arch
archives concerning how major subsystem changes are handled in their
rolling fashion.
I would not use, nor would I admin, a distribution which dropped GNOME
3 as a rolling update to GNOME 2 for users like Arch did. And I say
this as a reasonable satisfied GNOME 3 user with family who are also
currently reasonably satisfied GNOME 3 users, who opted out of
updating to F15 to keep a G2 environment for another 6 months before
making the switch to G3.


If Arch is the best model for a rolling release, and a model we would
pattern a Fedora rolling release on, then I'd probably not be
participating in such a rolling process. If other people value it and
can find the resources to set it up, I'll push packages into the
process and respond to bug reports as part of regular packaging work
to support regular releases, but I won't be using a rolling
day-to-day.

-jef
Bruno Wolff III
2012-01-25 19:29:52 UTC
Permalink
Personally I'd rather see the effort go into making it easier to update
between Fedora releases. That provides a way to remain fairly current without
starting from scratch and allowing you to choose the timing of when you want
to deal with disruption.
Michael Cronenworth
2012-01-25 19:33:49 UTC
Permalink
Post by Bruno Wolff III
Personally I'd rather see the effort go into making it easier to update
between Fedora releases. That provides a way to remain fairly current without
starting from scratch and allowing you to choose the timing of when you want
to deal with disruption.
What's wrong with preupgrade?
Ralf Ertzinger
2012-01-25 22:53:12 UTC
Permalink
Hi.
Post by Michael Cronenworth
What's wrong with preupgrade?
Every other release doubles the space needed in /boot for it to
work?
Bruno Wolff III
2012-01-25 23:01:55 UTC
Permalink
On Wed, Jan 25, 2012 at 13:33:49 -0600,
Post by Michael Cronenworth
Post by Bruno Wolff III
Personally I'd rather see the effort go into making it easier to update
between Fedora releases. That provides a way to remain fairly current without
starting from scratch and allowing you to choose the timing of when you want
to deal with disruption.
What's wrong with preupgrade?
I usually use yum to do upgrades, so I don't have a list of items for
improving preupgrade specifically, but we do have issues with obsoletes
not being correct and versions being lower in newer releases. There has
been improvement in this area, but we could do better.
We could do more to handle needed configuration changes where there
are incompatibilities when upgrading some packages. Probably people can
think of other things.
Maybe there could be suggestions to install new packages (say it is
noticed you have lots of games installed and maybe there would be a
suggestion that you might want to install some games that are new to the
new release) when upgrading.
Björn Persson
2012-01-25 23:28:01 UTC
Permalink
Post by Michael Cronenworth
What's wrong with preupgrade?
Preupgrade makes no effort to verify the authenticity of the new release it
downloads, so it's only usable for throw-away boxes where you don't care too
much if you get a backdoor or two installed together with your new Fedora
release.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120126/a5f7553d/attachment.sig>
Henrique Junior
2012-01-25 23:37:36 UTC
Permalink
Post by Björn Persson
Post by Michael Cronenworth
What's wrong with preupgrade?
Preupgrade makes no effort to verify the authenticity of the new release it
downloads, so it's only usable for throw-away boxes where you don't care too
much if you get a backdoor or two installed together with your new Fedora
release.
Björn Persson
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I would like to see Fedora following the path of rolling release.
openSUSE is doing a great job with the Tumbleweed, still keeping the
same old system of releases and letting users choose whether or not
using roling release.
Particularly I wouldn't like to see this thread dying as happened in
other occasions, after all, we know that discussions may not lead to
anything, and sometimes small actions can be more productive than long
threads [1]. I wonder if we could create a poll (for active members
with FAS accounts) to determine what the community thinks about it.
After the poll, if the idea of ​​rolling release receives most votes
then would be the time to discuss "how" and "when" doing the
implementation.

[1] - http://lists.opensuse.org/opensuse-project/2010-11/msg00206.html
--
Henrique "LonelySpooky" Junior
Kevin Fenzi
2012-01-26 01:19:40 UTC
Permalink
On Wed, 25 Jan 2012 21:37:36 -0200
Post by Henrique Junior
I would like to see Fedora following the path of rolling release.
openSUSE is doing a great job with the Tumbleweed, still keeping the
same old system of releases and letting users choose whether or not
using roling release.
Particularly I wouldn't like to see this thread dying as happened in
other occasions, after all, we know that discussions may not lead to
anything, and sometimes small actions can be more productive than long
threads [1]. I wonder if we could create a poll (for active members
with FAS accounts) to determine what the community thinks about it.
After the poll, if the idea of ​​rolling release receives most votes
then would be the time to discuss "how" and "when" doing the
implementation.
I would personally advise against this way forward. I'd like to suggest
an alternative:

* Gather folks interested in this (you should be able to see some from
this thread). Perhaps announce that you are forming a group to look
into this.

* Get together and write up a wiki page / detailed proposal, answering:

- How would this work?
- What resources would you need?
- What impact does it have on maintainers? users? release engineering?
- Would this work alongside the current setup? Or would it be one or
the other?
- Try and answer questions raised by folks in this thread.
- Try and list advantages. Why would we want to do this? what does it
get us?

* Post again once you have details and ask for more feedback.

* Repeat cycle until you find it's ready and then ask fesco to take a
look.

Just a suggestion...

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120125/49df5e9e/attachment.sig>
Frank Murphy
2012-01-26 08:05:26 UTC
Permalink
Post by Kevin Fenzi
I would personally advise against this way forward. I'd like to suggest
* Gather folks interested in this (you should be able to see some from
this thread). Perhaps announce that you are forming a group to look
into this.
+100
--
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
Markus Mayer
2012-01-26 08:55:29 UTC
Permalink
Post by Kevin Fenzi
On Wed, 25 Jan 2012 21:37:36 -0200
Post by Henrique Junior
I would like to see Fedora following the path of rolling release.
openSUSE is doing a great job with the Tumbleweed, still keeping the
same old system of releases and letting users choose whether or not
using roling release.
Particularly I wouldn't like to see this thread dying as happened in
other occasions, after all, we know that discussions may not lead to
anything, and sometimes small actions can be more productive than long
threads [1]. I wonder if we could create a poll (for active members
with FAS accounts) to determine what the community thinks about it.
After the poll, if the idea of ​​rolling release receives most votes
then would be the time to discuss "how" and "when" doing the
implementation.
I would personally advise against this way forward. I'd like to suggest
* Gather folks interested in this (you should be able to see some from
this thread). Perhaps announce that you are forming a group to look
into this.
- How would this work?
- What resources would you need?
- What impact does it have on maintainers? users? release engineering?
- Would this work alongside the current setup? Or would it be one or
the other?
- Try and answer questions raised by folks in this thread.
- Try and list advantages. Why would we want to do this? what does it
get us?
* Post again once you have details and ask for more feedback.
* Repeat cycle until you find it's ready and then ask fesco to take a
look.
Just a suggestion...
kevin
+1 Create suggestion

I would like to join such a SIG.

regards

Markus
Henrique Junior
2012-01-26 11:37:40 UTC
Permalink
Post by Markus Mayer
Post by Kevin Fenzi
On Wed, 25 Jan 2012 21:37:36 -0200
Post by Henrique Junior
I would like to see Fedora following the path of rolling release.
openSUSE is doing a great job with the Tumbleweed, still keeping the
same old system of releases and letting users choose whether or not
using roling release.
Particularly I wouldn't like to see this thread dying as happened in
other occasions, after all, we know that discussions may not lead to
anything, and sometimes small actions can be more productive than long
threads [1]. I wonder if we could create a poll (for active members
with FAS accounts) to determine what the community thinks about it.
After the poll, if the idea of rolling release receives most votes
then would be the time to discuss "how" and "when" doing the
implementation.
I would personally advise against this way forward. I'd like to suggest
* Gather folks interested in this (you should be able to see some from
  this thread). Perhaps announce that you are forming a group to look
  into this.
- How would this work?
- What resources would you need?
- What impact does it have on maintainers? users? release engineering?
- Would this work alongside the current setup? Or would it be one or
  the other?
- Try and answer questions raised by folks in this thread.
- Try and list advantages. Why would we want to do this? what does it
  get us?
* Post again once you have details and ask for more feedback.
* Repeat cycle until you find it's ready and then ask fesco to take a
  look.
Just a suggestion...
kevin
+1 Create suggestion
I would like to join such a SIG.
regards
Markus
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Did we have someone to lead this process?
--
Henrique "LonelySpooky" Junior
Frank Murphy
2012-01-26 11:44:17 UTC
Permalink
Post by Henrique Junior
Did we have someone to lead this process?
possibly the op
--
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
Mark Bidewell
2012-01-26 17:15:01 UTC
Permalink
I just had a conversation which I believe sheds some light on the
problem which a rolling release is trying to solve. The example is
Ubuntu bu you could apply the same to Fedora/RHEL.

My coworker wants to use Ubuntu LTS for development on Heroku. He
wants the stability of an LTS, but he needs a later version of Ruby to
run the Heroku tools. He has found that there is not supported way to
upgrade Ruby short of recompiling Ruby or upgrading his entire system.
Because of this he has returned to developing on OS X which handles
the Ruby upgrade.

I understand the cry of "what about dependencies?" However, if Linux
is to succeed we need to be able to be able to work with cases like
this one which OS X are fine with i.e. where only one or two packages
out of an entire system need to be upgraded leaving the rest of the
system alone.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
Frank Murphy
2012-01-26 17:37:48 UTC
Permalink
Post by Mark Bidewell
My coworker wants to use Ubuntu LTS for development on Heroku. He
wants the stability of an LTS, but he needs a later version of Ruby to
run the Heroku tools. He has found that there is not supported way to
upgrade Ruby short of recompiling Ruby or upgrading his entire system.
Because of this he has returned to developing on OS X which handles
the Ruby upgrade.
Supported by Fedora or Ruby?
--
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
Mark Bidewell
2012-01-26 17:43:10 UTC
Permalink
Post by Frank Murphy
My coworker wants to use Ubuntu LTS for development on Heroku.  He
wants the stability of an LTS, but he needs a later version of Ruby to
run the Heroku tools.  He has found that there is not supported way to
upgrade Ruby short of recompiling Ruby or upgrading his entire system.
 Because of this he has returned to developing on OS X which handles
the Ruby upgrade.
Supported by Fedora or Ruby?
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Since he was using Ubuntu I will say distro-supported, but if he was
using Fedora it would be Fedora supported. Ruby does not maintain
distro specific packages. Ubuntu has PPAs but these are somewhat
spotty for some software.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
Frank Murphy
2012-01-26 17:49:05 UTC
Permalink
Post by Mark Bidewell
Since he was using Ubuntu I will say distro-supported, but if he was
using Fedora it would be Fedora supported. Ruby does not maintain
distro specific packages. Ubuntu has PPAs but these are somewhat
spotty for some software.
Sorry, I meant if he wasn't worried about Fedora supporting his Ruby.
He could have used rvm to keep updated.
ditto Ubuntu.
--
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
Mark Bidewell
2012-01-26 17:52:01 UTC
Permalink
Post by Frank Murphy
Post by Mark Bidewell
Since he was using Ubuntu I will say distro-supported, but if he was
using Fedora it would be Fedora supported.  Ruby does not maintain
distro specific packages.  Ubuntu has PPAs but these are somewhat
spotty for some software.
Sorry, I meant if he wasn't worried about Fedora supporting his Ruby.
He could have used rvm to keep updated.
ditto Ubuntu.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I will look at rvm. thanks
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
Rahul Sundaram
2012-01-26 17:40:09 UTC
Permalink
Post by Mark Bidewell
I just had a conversation which I believe sheds some light on the
problem which a rolling release is trying to solve. The example is
Ubuntu bu you could apply the same to Fedora/RHEL.
My coworker wants to use Ubuntu LTS for development on Heroku. He
wants the stability of an LTS, but he needs a later version of Ruby to
run the Heroku tools.
Rolling releases won't solve this problem because your coworker wants
the stability of long releases. He wants the base to be stable and edges
to be fluid.

He has found that there is not supported way to
Post by Mark Bidewell
upgrade Ruby short of recompiling Ruby or upgrading his entire system.
Because of this he has returned to developing on OS X which handles
the Ruby upgrade.
I understand the cry of "what about dependencies?" However, if Linux
is to succeed we need to be able to be able to work with cases like
this one which OS X are fine with i.e. where only one or two packages
out of an entire system need to be upgraded leaving the rest of the
system alone.
The solution that Mac OS X has come up with is bundling however the
problem is that Linux is not a monolithic platform like Mac OS X and the
amount of bundling you have to do is much higher. Nothing other than
kernel or maybe glibc can be guaranteed to exist. There are some tools
in this area. glick for instance:

http://people.gnome.org/~alexl/glick2/

Rahul
Kevin Fenzi
2012-01-26 17:51:25 UTC
Permalink
On Thu, 26 Jan 2012 12:15:01 -0500
Post by Mark Bidewell
I just had a conversation which I believe sheds some light on the
problem which a rolling release is trying to solve. The example is
Ubuntu bu you could apply the same to Fedora/RHEL.
My coworker wants to use Ubuntu LTS for development on Heroku. He
wants the stability of an LTS, but he needs a later version of Ruby to
run the Heroku tools. He has found that there is not supported way to
upgrade Ruby short of recompiling Ruby or upgrading his entire system.
Because of this he has returned to developing on OS X which handles
the Ruby upgrade.
...snip...

This is the age old LTS 'use case'.

I want:

* A super stable platform.

* Backporting security fixes only and tons of testing and care.

* Minimal updates, only the backported security fixes after massive
testing.

oh, and:

* The very latest git head of php, python, ruby, or some other very
very specific component.

The problem here is that these are opposite goals. And they are also
exclusive... ie, I might want the very latest php and nothing else, but
$otheruser may want stable php but the latest ruby.

It's hard to win here. ;)

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120126/7a3fa9ed/attachment.sig>
Elder Marco
2012-01-26 11:43:43 UTC
Permalink
Post by Kevin Fenzi
I would personally advise against this way forward. I'd like to suggest
* Gather folks interested in this (you should be able to see some from
this thread). Perhaps announce that you are forming a group to look
into this.
- How would this work?
- What resources would you need?
- What impact does it have on maintainers? users? release engineering?
- Would this work alongside the current setup? Or would it be one or
the other?
- Try and answer questions raised by folks in this thread.
- Try and list advantages. Why would we want to do this? what does it
get us?
* Post again once you have details and ask for more feedback.
* Repeat cycle until you find it's ready and then ask fesco to take a
look.
Just a suggestion...
+1
Good idea!
--
Elder Marco

GNU/Linux User: #471180

"Contra o positivismo, que pára perante os fenÎmenos e diz: 'Há apenas
fatos', eu digo: 'Ao contrário, fatos é o que não há; há apenas
interpretações'. "(Nietzsche)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120126/e100b022/attachment.html>
drago01
2012-01-25 08:48:21 UTC
Permalink
Post by mike cloaked
Having looked at the way releasing packages and versions in linux has
been moving in a number of distributions it is interesting that there
are several that now have a rolling-release model.
http://www.omgubuntu.co.uk/2011/03/debian-cut-a-new-rolling-release/
http://cut.debian.net/
This is just a proposal.  Wont happen.
Post by mike cloaked
http://en.opensuse.org/Portal:Tumbleweed
Seems to be not actively adopted
Post by mike cloaked
https://wiki.archlinux.org/index.php/Arch_Linux
This is only distro that gained any traction with this model
Post by mike cloaked
Gentoo is also essentially a rolling release distribution.
Fedora would appear to be out of line in not taking on board the
potential user base for a rolling release version.
I dont think there is a massive user base waiting for a rolling release
really. Rolling release automatically implies a level of disruption
periodically everytime a major component is bumped up. Esp for binary
distros, this isn't that great a user experience. I would participate in
such a effort but I don't buy the idea of this as a trend
Exactly releases have the advantage of being a well tested set of
updates where you have a window to decide whether you want to update
yet or not.
So I don't see what a rolling release gains really. If you always want
to run the latest and greatest run rawhide (and help make it usable).
Genes MailLists
2012-01-25 12:48:04 UTC
Permalink
Post by drago01
Exactly releases have the advantage of being a well tested set of
updates where you have a window to decide whether you want to update
yet or not.
So I don't see what a rolling release gains really. If you always want
to run the latest and greatest run rawhide (and help make it usable).
There seems to be some confusion about this - rolling releases have
dev and testing just like periodic releases - and there's no reason at
all they cannot get at least (if not more) testing than a chunky release.

Centos/RHEL et al are antipodal to a rolling release - they have
lagging updates - languishing kernel and ancient apps after a while .. a
rolling release stays pretty current all the time ... quite a bit
different really.

An enterprise may want a LTS kernel - and the kernel team does indeed
offer that - the long term stable kernel is now in the 3.x series. A
rolling release can offer LTS kernel if there is desire for that too.

For enterprise setting - as I said earlier in the thread, its likely
many would rather have series of smaller updates than 1 gigantic update
every 2-3 years ... the latter can be unpleasant and disruptive. Doing
it once a quarter (say) on the other hand and dealing with small number
of changes is far more desirable and less disruptive.

I'd hazard a guess that anywhere software is developed for in house
use follows exactly this route - whether the production rollout is
monthly or more or less - and internal dev is almost always rolling.

There is every reason to believe that fedora (and RRHEL = rolling RHEL
heh heh) would be an improvement and certainly no less stable than what
we have now.

In fact if this route was taken, I'd guess this would be the killer
distro ...

gene
drago01
2012-01-25 13:15:20 UTC
Permalink
Post by drago01
Exactly releases have the advantage of being a well tested set of
updates where you have a window to decide whether you want to update
yet or not.
So I don't see what a rolling release gains really. If you always want
to run the latest and greatest run rawhide (and help make it usable).
 There seems to be some confusion about this - rolling releases have
dev and testing just like periodic releases - and there's no reason at
all they cannot get at least (if not more) testing than a chunky release.
Not really what about installation? Do you generate an image every
time you push updates?
Stay with an ancient install image that might not support current hardware?

I can't really see how a rolling release would gain us any more testing.
  An enterprise may want a LTS kernel - and the kernel team does indeed
offer that - the long term stable kernel is now in the 3.x series. A
rolling release can offer LTS kernel if there is desire for that too.
Enterprise just don't want unexpected changes without having time to
test it in their environment first.
  For enterprise setting - as I said earlier in the thread, its likely
many would rather have series of smaller updates than 1 gigantic update
every 2-3 years ... the latter can be unpleasant and disruptive.
Every such update requires testing before deployment ... doing it more
frequently would be more unpleasant ... but anyway fedora is not
really suited for use in an enterprise environment.
Continue reading on narkive:
Loading...