Announcing the release of Fedora 15 Beta!!

Przemek Klosowski przemek.klosowski at nist.gov
Tue Apr 26 17:59:44 UTC 2011


On 04/26/2011 01:11 PM, Kevin Kofler wrote:

> Retiring the packages is evil in the first place, and IMHO we're making it
> way too easy. Packages should only get retired if they are replaced by
> something different with equivalent or superior functionality or if they
> really cannot be made to work at all (e.g. because they depend on an online
> service that went away). The mere lack of an active maintainer shouldn't be
> a reason to retire a package.

I agree with your sentiment, but we have to avoid getting in a situation 
where unmaintained packages deteriorate to a point where they damage the 
reputation of the entire distribution. The older folk will remember with 
caution the old shareware repositories from the nineties: tons of 
software but overall poor quality and general waste of time.

Unfortunately, there's an infinitely fine spectrum of breakage, between 
'Fails to Compile From Source', through 'fails to run', to crashing on 
simple tasks, or on complex operations. I hope AutoQA can be used to 
detect breakage at higher levels than is currently the case. In any case 
we have to have some criteria on when we ban the broken package, but 
where do we draw the line?

I would even suggest that retiring packages is, in a way, 
counter-productive. If there's a person interested in some functionality 
to a sufficient degree so that they went out, found and installed the 
relevant software, that person might be actually interested in getting 
involved in fixing such package---so there may be some utility in 
keeping _slightly_ broken packages, even though too much and too broken 
stuff would be bad.

Perhaps it would make sense to flag packages that have known maintenance 
issues (whether known bugs or just lack of maintenance staff): say, pop 
a message box upon running directing people to existing  bugzilla 
entries and/or  maintainer signup page :) My point here is that if we 
can signal that the distribution knows and cares about breakage, and 
there's a way forward towards fixing it, the deficiencies don't look as bad.


More information about the devel mailing list