Re: Lintian based autorejects
Stefano Zacchiroli wrote:
> On Tue, Nov 03, 2009 at 09:28:01AM +0900, Charles Plessy wrote:
> On Mon, Nov 02, 2009 at 05:00:53PM -0800, Russ Allbery wrote:
>> Surely the answer to that question is obvious: fix the bugs Lintian is
>> finding that prevent upload. They're the equivalent of RC bugs (not
>> precisely the same, but similar), which if you're already doing an NMU are
>> certainly fair game.
>
> 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.)
>
> 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_? 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, maybe Russ' solutions is the one NMUers would
> implement anyhow and hence is overkilling to look for something more
> complicated.
It's quite clear that not fixing the issue in the NMU will mean no NMU
as it would get rejected. It's comparable to fixing an unrelated FTBFS
bug (even if not filed), there are some preconditions to get your upload
accepted in the archive. The automated upload rejections are just an
additional hurdle to be able to get your upload into the archive, so
should certainly be fixed in whatever upload you do IMHO.
Cheers
Luk
Reply to: