[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lintian based autorejects


On Dienstag, 27. Oktober 2009, Simon McVittie wrote:
> On Tue, 27 Oct 2009 at 15:06:07 +0100, Joerg Jaspert wrote:
> > The second category is named "error" and the tags listed can not be
> > overridden.
> I don't think it's appropriate to make, for instance,
> dir-or-file-in-var-www instantly fatal without following the usual
> mass-bug-filing procedure. If you'd like mass bugs to be filed based on
> these lintian tags but don't have time, let me know if I can help (I can't
> promise to deal with all of them).
> I'm not arguing that dir-or-file-in-var-www is not a bug - it is - but it's
> a technical problem that needs a transition (moving files around,
> reconfiguration, probably a migration path in many cases), rather than just
> some incorrect boilerplate in debian/copyright that can easily be fixed
> before uploading. Thankfully, we have a procedure to deal with buggy
> packages, i.e. a bug tracking system :-) together with processes for NMU or
> removal of packages that are too buggy.

+1 from me for these two paragraphs.

Currently I have no idea how to fix any issues with munin in unstable (as I 
dont have a migration plan/path for /var/www/munin which I like/consider 
sensible) and the idea to upload munin 1.4 (which is scheduled for release in 
November/December this year) to experimental is stalled atm too, for the same 
reason. Which IMO is pretty sad.

> I'm in favour of auto-rejecting packages with very serious packaging
> problems, but auto-rejecting makes bugs "worse than RC", so IMO it's
> necessary to be more conservative about existing packages

+1 again.

> - if your package 
> has an RC bug open, you can still upload it to fix other (possibly RC)
> bugs, but if your package is being auto-rejected, you have no choice but to
> fix the auto-reject before the next (successful) upload.
> I realise this is somewhat deliberate, to give maintainers a strong
> incentive to fix their packages. However, it seems disproportionate: we
> don't enforce that for RC bugs, even those with severity 'critical', so
> this is effectively creating a class of bugs more severe than 'critical'.
> It seems unwise to do that without the relevant bugs at least being tracked
> as RC first!
> Some examples of tags I consider reasonable to auto-reject, because they
> should be easy to fix (but many of them should be bug reports anyway):
>     - binary-file-compressed-with-upx
>     - copyright-lists-upstream-authors-with-dh_make-boilerplate
>     - missing-dependency-on-perlapi
>     - section-is-dh_make-template
> Some examples of tags where I do not consider this reasonable until bugs
> have been filed:
>     - statically-linked-binary
>     - mknod-in-maintainer-script
>     - debian-rules-not-a-makefile
>     - dir-or-file-in-var-www

Again, +1.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: