On Mon, 2006-02-27 at 19:18 +0100, Thomas Viehmann wrote: > Note that individual maintainers can already configure dput to stop the > upload on lintian/linda errors.
Yes, but the point raised was whether it would be better to centralise that. There are a lot of opportunities to run lintian but appearently a lot of packages with errors/warnings are being uploaded. > > Since these tools can already differentiate between errors and warnings, > > it would make sense to define the subset for rejection as "all errors". > > I'm afraid I have to disagree here. An old FSF address doesn't warrant a > reject. Neither do false positives in lintian, they do happen (e.g. the > last C++ transition would have been impeded, in fact l.d.o still shows > lintian errors for "libfoo0c2a"). > Effectively, this would only foster an increase in questionable > overrides. Lintian is a useful tool, but it's results need to be subject > to review before filing bugs or doing rejects. The original poster talked about a "subset of errors" to reject a package on. I do think that introducing a third category of lintian problems (warnings, errors, and now reject-errors) doesn't help, if we want to go through with this, we need to clearly define what problems are errors (i.e.: not acceptable in the archive) and reject them instead of inventing another category. Thijs
signature.asc
Description: This is a digitally signed message part
