Orcan Ogetbil oget.fedora at
Thu Sep 23 07:42:41 UTC 2010

On Wed, Sep 22, 2010 at 4:45 PM, Adam Jackson wrote:
> On Wed, 2010-09-22 at 22:21 +0200, Till Maas wrote:
>> This here sounds strange:
>> | The update rate for any given release should drop off over time,
>> | approaching zero near release end-of-life; since updates are primarily
>> | bugfixes, fewer and fewer should be needed over time.
>> This essentially says that after 12 or 18 months all software in Fedora
>> is bug free and does not need any updates. This is a very strange
>> assumption. E.g. why do we stop supporting the software after it became
>> totally stable? IMHO this claim cannot reasonably be made.
> There is a difference between "stable" and "bug free".  Known
> limitations are preferable to moving targets.
> Again: if we kept updating everything to the very latest thing all the
> time, why even bother doing releases.  Everyone would just run rawhide.
> Right?

There is a difference between "updating everything to the very latest
thing" and "rawhide". With sufficient testing, everything can go to
the stable repo, provided that it doesn't make a significant change in
behavior (but then a significant change in behavior wouldn't pass the
sufficient testing stage). In the case of rawhide, the "sufficient
testing" time is considered to be the time the update stays in rawhide
until the next release.

The difference between the two can be eliminated only with manpower
dedicated to testing, which we don't have. The main disagreement comes
when we try to standardize the updates procedure. Those packages
closer to the core of the OS obviously need more testing. What we need
is some sort of measure to determine this closure. This is difficult.

Even if we manage to come up with such a measure and determine the
minimum updates-testing time for each package based on it, certain
people will still be unhappy because the philosophy of certain
close-to-core package is to run the latest version.

I think Kevin's proposal is written fairly with the given information.
Still, I believe that the stable update guide needs to be relaxed for
software that doesn't affect anything other than itself. There are
single library packages that are not used by any applications, or used
by at most 1 application. The API/ABI change in a stable release
wouldn't break anything for such libraries.


More information about the devel mailing list