Robin Laing wrote:
You make my point. As a user I hate the idea of having to do a new
install every six months or skip a release and it is once a year.
Yes. I completely understand that. That is something we are trying to
solve but I dont consider rolling updates as a answer to these issues.
See below for more details.
I would prefer that there be an easy upgrade path throughout the year.
Thus, the developers can make changes to Z application and have that go
out to the Fedora crowd. Now if there is a major change, such as udev,
then this can get complicated but not impossible. It is possible to
upgrade from FC4 to FC6, I have done it. Now if it was FC4, FC4.1,
FC4.2 ... FC6, then the upgrade would have been painless and happen with
normal yum updates. Is yum/rpm smart enough to handle this?
It is not a question of package managers. The problems lie elsewhere.
For example, no package manager is capable of automatically updating
from LVM1 to LVM2 format. They are incompatible formats and automatic
live upgrade just isnt possible or atleast it is outside the scope of
package managers as such. Now this isnt usually the case and the
problems with live upgrades using yum can be made better and work is
being done on that. This would make it far more easier for users to
upgrade their Fedora systems without moving into a rolling updates model.
* Make sure that every single package always has a proper update path
and dependencies are resolvable through checks before every package
release in the updates system. See
http://fedoraproject.org/wiki/Releases/FeatureUpdateSystem
* Possibly decouple the upgrade process from Anaconda. See
http://barcamp.org/FudconBoston2007#SESSIONS
* Different spins and tools to customize and creative derivatives which
would ensure that you dont install a whole lot of unnecessary packages
which affect the chances of a smooth upgrade. See
http://fedoraproject.org/wiki/Releases/FeatureCustomDistro
* Continue to make things that affect a update process a important
criteria for a release. See http://fedoraproject.org/wiki/QA
There are other changes in the pipeline too.
I can agree that a major change could be a real headache but if the
changes are grouped, lets say the move to PATA as part of the kernel
upgrade, then most applications can be updated at the same time. Now, I
remember doing a kde update that was massive so why not a change like
that. There is still the testing branch to work things out on.
Not many people are prepared to help out and provide feedback in
updates-testing. Have you on a regular basis? A KDE update is small
potatoes compared to other fundamental changes we are making with every
release. Some of them like in GCC or Glibc requires rebuilding every
single component in the distribution. If you want such massive changes
as updates within the same release, you might as well as be running the
Fedora development tree.
Is the present system a deal breaker for Fedora? With the loss of
legacy support for older versions, it is looking more and more that it
could be.
I don't consider it a deal breaker but a rolling release model with
major changes now and then is just too problematic if you want a
somewhat robust release. A slightly longer updates cycle might have been
better as I said elsewhere before. Fedora updates lifetime has increased
updates lifecyle to two releases. That means previously FC4 received
main updates till FC6 test 2 was released. Now when F7 is released, it
would get updates until F9 is releases which is from about 9 months to
about 13 months. That gives you the ability to completely skip one
release. If you want a longer lifecycle, you are free to get involved
and help.
Rahul
