Re: Lintian based autorejects
On Tue, Nov 03 2009, Stefano Zacchiroli wrote:
> I don't think it is that simple. <nitpick>For once, we need to refine
> some of our guidelines (that's the easy part). Devref §5.11.1 authorizes
> to upload only changes that fix RC bugs older than X days, so if lintian
> is complaining about issues not corresponding to RC bugs (e.g. because
> it is a new check in lintian, not yet reported), in theory you shouldn't
> upload with specific delays.</nitpick> (As I anticipated, that's the
> easy part, just fix the guidelines.)
Or recall that guidelines do not trump common sense, and do the
only thing that works in this case.
> In general though, I wonder whether that would be the right
> approach. Why should the NMUer be forced to fix other issues than her
> own (RC) itch, considering that other (indubitably grave) issues were in
> the archive _before_?
Thanks for asking. The solution, past a transition period, is
to get these packages fixed or removed from the archive; hence we
should be aggressively filing RC bugs on them.
> The ideal solution would be to have dak know the previous state and do
> not accept _regressions_ wrt the previous set of fatal upload errors
> (according to the proposed wording). I'm not sure it is worth though,
I beg to differ. In the long run, there should not be *any* such
violations in the archive; so it is not really worth spending time
writing code for dak that will shortly be a dead path.
> maybe Russ' solutions is the one NMUers would implement anyhow and
> hence is overkilling to look for something more complicated.
>
>> This answer is independent of what we decide should go into that set of
>> checks.
>
> ACK.
manoj
--
My, how you've changed since I've changed.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: