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

Re: Proposal for an advanced Debian-QA system

Il sab, 2004-02-21 alle 23:54, Adrian Bunk ha scritto:
> On Fri, Feb 20, 2004 at 10:37:22PM +0100, Bluefuture wrote:
> > This are some idea for an advanced automatic Debian-qa system:
> >...
> It's a common misunderstanding that automatic tools would be able to 
> solve every problem.
I don't belive that automatic tools would be able to solve
Intellectual/Social solvible problems.

> Automatic tools might help you to identify QA problems, but they are 
> only a help for resolving QA problems, not a solution themselves.
> > So this alert sensors could perform some automatical tasks. For example:
> > 
> > - Defcon 5 Send an automatic alert via email to Debian Qa
> What are the benefits of spamming Debian QA with hundreds of mails?

To take only as example
Defcon 5 ---> A package lacks/skips 3 Stable upstream relases and has 10
important unresolved bugs (??how many bugs could be resolved by an
upstream??) and have many bugs  in a state of "forwarded to the upstream
author" on BTS and there are 10 other packages depending on it and it
has an HIGH vote in popularitycontest and there isn't posted any
uploaded version of the actual package in the repos by 4 months etc.

Do you still want to call this: spamming to QA??

A Mantainer can put the Defcon system on "hold state" posting his
motivation in a filed on the QA DBMS "via Web interface?". 
But all the problems (Date lack between upstream and package in debian
repos etc. etc.) could be visible in a table for the comunity and the Qa
purposes. The problems of Alerts (open a bug, mail a report to QA etc.)
are marginal for me.
There will could be only a simple HTML like this
http://developer.skolelinux.no/info/cdbygging/distdiff.html that give an
overview of the problems of the packages in unstable for go in testing.

My idea could be a sort of upstream status overview for QA Developer and
Debian Comunity (not a system for systematically piss Mantainers): Why
Debian is not upstream updated?  

All this in a clear way.

> > - Defcon 4 Send an automatic email to Debian Qa and open an automatic
> > wishlist or minor bug on the package.
> Never ever open a bug without checking whether a similar bug is already 
> open.

This could be a sort of Bug that result opened by QA: "Your package has
reached Defcon 4. 
Plese put on hold on the Defcon monitor system for your package filling
a motivation in the "Web Form" in the QA DBMS for Qa purposes. If a
Mantainer is not "negligent" can set on hold (with varius type of "on
hold" status?? -busy with exams, dependency problems etc.-) the Defcon
system with a valid motivation before package reach the Defcon 4 status.

> Never ever automatically send bug reports. It's OK to let a script 
> automatically generate bug reports, but do not send them unless you 
> checked every single package whether the issue really exists.
> > - Defcon 3 Send an automatic alert via email to the Mantainer requesting
> > info about lack.
> >...
> If the maintainer already told you a good reason why he can't resolve 
> this issue he'll be quite pissed off if he gets an automated mail 
> requesting more information.

I have explain this point before.


Reply to: