On Tue, 17 Jan 2012 09:54:39 -0500, SG (Stephen) wrote: > On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote: > > While that makes some sense, it was not my point. My point was that even if > > the package has NO maintainer, as long as it works, it's still better than > > no package at all! > > Not true. A package that appears to work, has people using it, but has > no one maintaining it is likely to become a package that has exploitable > security issues. Kind of a poor example, albeit a valid one, too. Any bug might have an impact. The general question of "Who handles bug reports (including security related ones)?" is still unanswered. It doesn't even need to be a real security vulnerability. Any bug report that isn't handled can lead to shipping software that doesn't work or doesn't work well enough. Worse if bug reports pile up with nobody responding to them. Fedora users are annoyed, if bugzilla appears to be no better than /dev/null. Perhaps there would not be just a team that rebuilds hundreds to thousands of "unmaintained" and possibly unused packages as needed, in Kevin's scenario there might be a Security SIG that would handle [properly tracked] security issues. That doesn't answer above question, however. > I'm in favor of retiring unmaintained packages. At worst, it will > encourage someone to step up to re-add it if it is actually important. > This means a new package review, which is a good thing for dealing with > "specrot". So far so good, but disagreeing with the latter, because: Every approved Fedora Packager should be capable of discovering and getting rid of "specrot". Just because we make mistakes occasionally (and because some packagers have messed up important Obsoletes/Provides before), doesn't mean we should punish all packagers with an extra review request. Releng could have the final say after reviewing the old "dead.package" file that must mention why a package had been retired previously. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
