On 27/10/09 at 14:57 +0000, Simon McVittie wrote: > 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
I fully agree. Auto-rejecting should be limited to errors we absolutely do not want in our archive. For everything else, RC bugs should be used instead. Also, lots of packages currently in our archive already have those errors. What do you plan to do with those? If you auto-reject packages that introduce those errors, it would be logical to file RC bugs and/or remove them from the archive. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
