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

Re: Lintian based autorejects

Faidon Liambotis <paravoid@debian.org> writes:

> lintian already categorizes the bugs into “errors” and “warnings”. I'd
> personally prefer it if the ftp-master team didn't choose to hand-pick
> lintian tags themselves but trusted lintian and its maintainers.
> Possibly also by filling bugs to lintian or policy as appropriate.

The Lintian maintainers (at least me) explicitly asked the ftp team to not
do that.  I know I don't want to have that responsibility; I want someone
else to look at what Lintian is doing and make an independent decision.
This way, two groups need to have reviewed the check and agree that it's
worth issuing independently.

Also, note that the ftp team are at least project delegates, whereas the
Lintian maintainers are "just" package maintainers.  If we have a
governance problem with the ftp team making this decision, it would be
even worse if the Lintian maintainers were making this decision.

> I'd also prefer it if the QA team was involved somehow in all these,
> since, well, this is about “quality assurance”, isn't it?

I'm a little surprised to see the QA team brought up in this context since
I haven't really seen that much overlap between the sort of checks that
Lintian is doing and the sort of checks that the QA team has been working
on except at a very high level.  But I'd absolutely love to have them
involved if they're interested.

> While I also agree in principle with lintian-based autorejects and
> respect the work that has been done for this, I don't think that it fits
> the ftp-master job description to take such a decision.

I do think that they sought consensus on the idea, and while there were
objections in the previous discussion as well, my impression was that the
general feeling of the project was in favor.  However, I personally am in
favor and therefore may be a biased judge of consensus.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: