Stable update procedures

[Rahul Sundaram]

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.
>>
>> https://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines
>>
>> 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
> reason."

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

http://fedoraproject.org/wiki/Objectives

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 
less.

Hope that helps.

Rahul