Re: Lintian based autorejects

[Stefano Zacchiroli]

[ Adding -qa to Cc ]

On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> > For future handling: If we are adding tags to the list that will hit
> > more than a few packages we will send a notice to the d-d-a list.
>
> I don't think it's appropriate for the ftp team to add any other checks
> without notifying the project, regardless of how many packages are currently
> affected.  Please make sure you notify the project of /any/ additional rules
> you apply at archive accept time.

ACK on this.

While I heartly welcome this addition, I see the centralization of the
tag decision process as potentially dangerous; not for "power" reasons,
but rather for the bad feelings (and related flamefests!) such changes
can leave behind and for the potential bottleneck risks (nowadays FTP
master is luckily and finally more stuffed than in the past, but
tomorrow who knows?).

So, I revamp a proposal I made in a corner of this thread:

  Let the QA team decide upon the non overridable lintian errors.

Rationale: the QA mailing list is considered to be a rather good venue
to discuss and reach consensus, also it is one of the places where
lintian maintainers discuss various issues, and (trivially) QA is the
supposed place where to enforce project-wide QA.
(Full disclosure: yes, I'm currently an active QA member.)

Of course this change proposal is not meant to force FTP masters to
implement support for that. If they agree on such change, it would be
more than reasonable for them to ask for a specific patch implementing
that technically.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

[Steve Langasek]

On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote:
> On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> > > For future handling: If we are adding tags to the list that will hit
> > > more than a few packages we will send a notice to the d-d-a list.

> > I don't think it's appropriate for the ftp team to add any other checks
> > without notifying the project, regardless of how many packages are currently
> > affected.  Please make sure you notify the project of /any/ additional rules
> > you apply at archive accept time.

> ACK on this.

> While I heartly welcome this addition, I see the centralization of the
> tag decision process as potentially dangerous; not for "power" reasons,
> but rather for the bad feelings (and related flamefests!) such changes
> can leave behind and for the potential bottleneck risks (nowadays FTP
> master is luckily and finally more stuffed than in the past, but
> tomorrow who knows?).

> So, I revamp a proposal I made in a corner of this thread:

>   Let the QA team decide upon the non overridable lintian errors.

My only concern is that the ftp archive checks not be used to force changes
in Policy.

If the set of tags being drawn from is limited to those that are recognized
as violations of Policy "must" requirements, then I have no opinion on who
should decide which tags are blockers and which ones are not.  If the
candidate tags are *not* limited to that set, then I think we have a
governance problem regardless of who's driving.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...

[Raphael Hertzog-3]

On Sun, 01 Nov 2009, Steve Langasek wrote:
> My only concern is that the ftp archive checks not be used to force changes
> in Policy.
>
> If the set of tags being drawn from is limited to those that are recognized
> as violations of Policy "must" requirements, then I have no opinion on who
> should decide which tags are blockers and which ones are not.  If the
> candidate tags are *not* limited to that set, then I think we have a
> governance problem regardless of who's driving.

What about using those tags to achieve release goals?

For example, the support of 3.0 (quilt) by default would benefit from
getting rid of:
http://lintian.debian.org/tags/patch-modifying-debian-files.html
http://lintian.debian.org/tags/quilt-patch-with-non-standard-options.html

Otherwise, I generally agree with your point of view. I welcome this new
infrastructure but the set of tags used should be limited to clear
violations of must directives, really broken packages, and other
consensual tags that allow us to reach our current set of goals.

Cheers,
--
Raphaël Hertzog


--
To UNSUBSCRIBE, email to debian-qa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stefano Zacchiroli]

On Sun, Nov 01, 2009 at 04:13:48PM -0800, Steve Langasek wrote:

> On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote:
> > So, I revamp a proposal I made in a corner of this thread:
> >   Let the QA team decide upon the non overridable lintian errors.
>
> My only concern is that the ftp archive checks not be used to force changes
> in Policy.
>
> If the set of tags being drawn from is limited to those that are recognized
> as violations of Policy "must" requirements, then I have no opinion on who
> should decide which tags are blockers and which ones are not.  If the
> candidate tags are *not* limited to that set, then I think we have a
> governance problem regardless of who's driving.

Agreed.

I was splitting the issues in two sub-issues actually: (1) being sure
that lintian "E:" messages are only those coming from violated "must"
requirements, (2) deciding which among them are upload blockers.

I confess I was pretty much assuming that lintian maintainers ensure (1)
is always verified. Beside bugs in lintian that can always, I now
realize that (1) is probably not so strict. For instance, for OCaml
packages we do have custom lintian checks that do not appear in policy,
but rather in our own packaging policy, but which we do want to be
"E:". Surely we do not want those to be upload blockers.

All in all, your requirement can be probably be implemented by setting
the general rule that all upload blockers should match violated "must"
requirements, no matter who is in charge of defining the list.

That rule being clear, we can decide upon anyone team to be in charge of
defining the list, I just found QA a good balance of factors like: "not
too big" (to avoid consensus reaching problem), "not too small" (to
avoid bottlenecks), "on topic" (in charge of archive QA).

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

[Lucas Nussbaum]

On 01/11/09 at 15:31 +0100, Stefano Zacchiroli wrote:

> [ Adding -qa to Cc ]
>
> On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> > > For future handling: If we are adding tags to the list that will hit
> > > more than a few packages we will send a notice to the d-d-a list.
> >
> > I don't think it's appropriate for the ftp team to add any other checks
> > without notifying the project, regardless of how many packages are currently
> > affected.  Please make sure you notify the project of /any/ additional rules
> > you apply at archive accept time.
>
> ACK on this.
>
> While I heartly welcome this addition, I see the centralization of the
> tag decision process as potentially dangerous; not for "power" reasons,
> but rather for the bad feelings (and related flamefests!) such changes
> can leave behind and for the potential bottleneck risks (nowadays FTP
> master is luckily and finally more stuffed than in the past, but
> tomorrow who knows?).
>
> So, I revamp a proposal I made in a corner of this thread:
>
>   Let the QA team decide upon the non overridable lintian errors.
>
> Rationale: the QA mailing list is considered to be a rather good venue
> to discuss and reach consensus, also it is one of the places where
> lintian maintainers discuss various issues, and (trivially) QA is the
> supposed place where to enforce project-wide QA.
> (Full disclosure: yes, I'm currently an active QA member.)

I don't think that it's a good idea to give the reviewing power to the
QA team: QA team membership is loosely defined, and if we were to make
policy decisions, we would have to have a clear process to determine who
is empowered to take those decisions.

I'm fine with letting ftpmasters take that decision. However, they
should consult the project before adding new tags (mail to -devel: "We
are thinking of adding those new tags to our list, comments?" instead of
a mail to -devel saying "We just blocked the following tags"), and
listen to feedback. If someone feel that they made a mistake, it's
always possible to appeal to the TC.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-qa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Faidon Liambotis-2]

Lucas Nussbaum wrote:
> I'm fine with letting ftpmasters take that decision. However, they
> should consult the project before adding new tags (mail to -devel: "We
> are thinking of adding those new tags to our list, comments?" instead of
> a mail to -devel saying "We just blocked the following tags"), and
> listen to feedback. If someone feel that they made a mistake, it's
> always possible to appeal to the TC.
Is it?

By my interpretation, I don't think that the TC has any authority here
since the ftp-masters are DPL delegates and not individual maintainers.

Regards,
Faidon


--
To UNSUBSCRIBE, email to debian-qa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Stefano Zacchiroli <zack@...> writes:

> I was splitting the issues in two sub-issues actually: (1) being sure
> that lintian "E:" messages are only those coming from violated "must"
> requirements, (2) deciding which among them are upload blockers.

> I confess I was pretty much assuming that lintian maintainers ensure (1)
> is always verified.  Beside bugs in lintian that can always, I now
> realize that (1) is probably not so strict. For instance, for OCaml
> packages we do have custom lintian checks that do not appear in policy,
> but rather in our own packaging policy, but which we do want to be
> "E:". Surely we do not want those to be upload blockers.

Right.  Lintian E: tags are not now and never have been only Policy must
directives.  They correspond to tags that, were one to file a bug about
them, would be either severity serious or higher or severity important
with a certainty of possible or higher.  This includes things that aren't
in Policy at all but that denote broken packages, Policy should directives
that are easy to fix, misuses of tools according to the documentation of
that tool that aren't mentioned in Policy at all, and a few other things.

> All in all, your requirement can be probably be implemented by setting
> the general rule that all upload blockers should match violated "must"
> requirements, no matter who is in charge of defining the list.

I do think it's reasonable to not allow people to upload packages with
obvious and easily-correctable errors even if they're not must directives,
although I suppose we could implement that by upgrading all such errors
to must in Policy.

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


--
To UNSUBSCRIBE, email to debian-qa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 02/11/09 at 12:10 +0200, Faidon Liambotis wrote:

> Lucas Nussbaum wrote:
> > I'm fine with letting ftpmasters take that decision. However, they
> > should consult the project before adding new tags (mail to -devel: "We
> > are thinking of adding those new tags to our list, comments?" instead of
> > a mail to -devel saying "We just blocked the following tags"), and
> > listen to feedback. If someone feel that they made a mistake, it's
> > always possible to appeal to the TC.
> Is it?
>
> By my interpretation, I don't think that the TC has any authority here
> since the ftp-masters are DPL delegates and not individual maintainers.

I don't think that this was raised as a blocker when the TC was asked to
overrule ftpmasters about the ia32-lib-tools removal. (but please
correct me, I'm clearly not a constitution expert)
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-qa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...