Stable update procedures
sundaram at fedoraproject.org
Thu Feb 12 05:25:07 PST 2009
Vincent Untz wrote:
> Le jeudi 12 février 2009, à 13:36 +0530, Rahul Sundaram a écrit :
>> For Fedora, a new set of guidelines got approved recently.
>> It doesn't answer all your questions since there is a lot of work in
>> progress still. I will try and add references to the above guidelines
>> when they are in use.
> I find it interesting that in Fedora, you have something like "New
> upstream releases should not necessarily be pushed to release branches."
> I expect most other distros to have "New upstream releases are strongly
> discouraged in release branches, unless you have a really really good
The sentences right after are:
"The benefit of the bugfixes and new features should be weighed up
against the risk of regressions. A simple rule of thumb might be to not
push the new release unless it fixes a problem that a user has reported
or introduces a new feature that Fedora users have previously requested."
> Is there any reason for this approach?
[I proposed the original update guidelines which were substantially
revised to what you see now. Following is my take on why I considered
this a good approach. Some of the Fedora contributors opposed the move
heavily so I am sure others have a different take on it.]
I think it would vary depending on the goals of the distribution.
Fundamentally, one of the primary goals of Fedora it to push Free and
open source software forward
Fedora often acts as a technology showcase for upstream projects. It is
not unusual for Fedora to have new features via updates and not limited
to just bug and security fixes. New upstream kernel versions are
routinely pushed in an updates. KDE 4.2 is now available as an update
for Fedora 9 (which got 4.1 earlier as an update as well) and Fedora 10
and not just rawhide (development branch)
Also, the general idea of the guidelines is that by describing the goal
(which is to avoid or atleast reduce the amount of regressions as much
as possible), maintainers who are most close to the respective upstream
projects they are packaging can consider whether to push new upstream
versions, backport fixes or not do anything depending on the upstream
status (stability of current version, , demand for new versions from
users, generally history of regressions in new versions for that project
etc). Discouraging new upstream versions doesn't necessarily lead to a
better experience with regard to regressions.
Again going back to the KDE example, Fedora 9 included KDE 4.0.x as the
default KDE environment with a few KDE 3 packages to fill in the gaps
but no parallel installable KDE 3 desktop environment for reasons
outlined in http://fedoraproject.org/wiki/SIGs/KDE/KDE4FAQ. As is now
well known, we received some heat on this decision but also a lot of
demands from users who wanted 4.1 and later 4.2 as updates because it
fixed a number of outstanding issues they were facing on a regular
basis. KDE 4.2 especially has been well received and is generally
considered a much more robust release compared to previous versions. in
this case, discouraging upstream revisions from being pushed as updates
would have resulted in more users suffering from regressions rather than
Hope that helps.
More information about the Distributions