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

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.

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: