'outdated' packages in rawhide

[Mike A. Harris]

On Sat, 13 Mar 2004, Xose Vazquez Perez wrote:

>> .. and what is the problem with not having the absolute bleeding edge
>> every day of the week ? Updating packages costs time, and not all
>> changes in new upstream releases warrant spending that time immediately,
>> nor does it always warrant invalidating the testing on the currently
>> stable package.
>
>This is not taroon ml ;-).

Developer time is developer time though, wether it is being spend 
developing on RHEL, or time spent developing on Fedora Core.  

Updating a package to a new version does not come at zero 
developer time cost.  Depending on the particular package, the 
changes it includes, and how those changes might affect other 
packages in the distribution or dependancies need to be 
investigated closely.  It may also require upgrading other things 
too that other package owners maintain, which might continue in a 
domino effect across the distribution depending on the package.  

While that doesn't happen for every package every time, it does 
happen enough that it has to be taken seriously so we're not 
wasting our time.

If I spend an hour updating xchat for example, and then a week 
from now a new version comes out and I spend another hour on it, 
and then several other times in the devel cycle I update it 
again, that might be a total of 8 hours spent working on xchat.  

That's 1 work day out of a year.  We have to ask ourselves if it 
is good use of Red Hat's resources to do that or not.  For some 
packages it is, and the overhead of making the changes is small.  

For other packages it is not, and the overhead is large - and 
might not be immediately visible until you start doing the work - 
or worse, until after you've updated it and find out the new 
version of whatever you updated is loaded full of bugs and break 
in ways you might not have time to fix with your current 
schedule and priorities.  You either then ship buggier but newer 
bits, or downgrade back to the old version and irritate a lot of 
people due to yum/up2date/apt not liking the package downgrade.

Another problem which Arjan touched upon, is that when you 
upgrade a package to a new version, you lose the benefit of all 
of the beta testing done on that package up to that point.  If it 
is a library, then all of the applications that link to it have 
lost their beta testing as well, because the library could now 
be introducing a bug that affects a large part of the OS.  Again, 
different packages have different importance levels and impact in 
this regard.

As someone pointed out, updating openssl would probably be bad
due to the amount of work required, and the fact that that is a
critical part of the OS, which you want to maximize beta testing
and not take chances.  But updating something such as procinfo is 
unlikely to cause major problems.

So you're right, this is not Taroon, and we do ride the edge a 
little closer in Fedora Core, but that must be done very 
responsibly if we want Fedora Core to also be a reliable and 
useable OS.  If a large part of the OS is updated near the end of 
the cycle, and most beta testing is lost, then the release will 
ship with many major problems, a lot of them only being found out 
after the release goes out the door.  Then nobody will want to 
use it, it will get bad press reviews and negative feedback from 
the community, and the project suffers.

It is nice to have newer versions of packages, but that has to be 
decided on a package by package basis, based on the merits of 
what each individual package benefits from if it is updated, and 
how much that matters in the grand scheme of things, balanced 
with how much man hour resources are needed to do all the work, 
etc.

It is a gentle balancing game.  That said, I think all of my
packages are up to date except for XFree86, but we know the
answer there.  ;o)



-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat