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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
