Re: Lintian based autorejects
Steve Langasek <firstname.lastname@example.org> writes:
> On Sun, Nov 01, 2009 at 02:31:19PM -0800, Russ Allbery wrote:
>> All Manoj is doing is filing bugs. Anyone can do that. I don't see any
>> reason why that would make anything harder in the long run.
> I have seen him assert in a bug on one package that I'm subscribed to
> that the package has been "deemed too buggy to be in Debian", and that
> this justifies a "serious" severity on the bug - effectively affirming
> that the ftp team has the right to arbitrarily overrule Policy. I think
> that's a problem.
We have arguments over bug severity all the time, and therefore have an
established mechanism for deciding who gets to declare things serious.
I'm not sure why this is any different than the bug severity arguments we
>> We knew this decision by the ftp team was coming for a while, and will
>> require checking against our other documents and probably changes to
>> the severity of various rules.
> And I objected before when this was first proposed that the ftp team
> should not be auto-rejecting from the archive for any issues that are
> not violations of Policy "must" requirements.
> The right process is: discuss; reach a consensus; amend Policy; enforce
> The wrong process is: the ftp team declares that certain bugs are
> blockers for inclusion in the archive, and Policy is left to scramble to
> keep up with documenting this.
Yeah, I know how you feel about this.
I'm not unsympathetic, but I personally don't mind the ftp team being
somewhat more proactive than that. A lot of the bugs that they've marked
as rejects are pretty obvious and easy-to-fix bugs, and I'm not sure why
the project as a whole should spend time filing bugs about them when the
Lintian checks in question have an essentially 0% false positive rate and
the fix is fairly obvious. Even if it's not something that's going to
break the package, why not do it right when it's fairly easy to do so?
One can essentially always have an argument about anything we do in Debian
that it should have been done a different way, in a different order, with
different communication, and so forth. I'm not saying those arguments are
wrong, just that I guess I feel like we'll get to a reasonable outcome and
I'm not feeling too worried about it.
There are some tags in the first set that probably shouldn't stay in there
because my description above is not correct for them. Being iterative
about this isn't a bad thing.
I'd feel more comfortable saying that everything should go through the
Policy process if the Policy process were working in a timely manner.
It's not. I'm not sure how to fix that other than clone Debian
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>