Re: Proposal for an advanced Debian-QA system
On Sun, Feb 22, 2004 at 02:20:14AM +0100, Bluefuture wrote:
>...
> > > 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
Even a package with over 100 open important bugs might be well
maintained.
There's no direct correlation between the number of open important bugs
and activity of upstream or the Debian maintainer.
> 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.
> etc.
With these rules, you won't catch many packages with problems.
No matter how you set the rules exactly, you will either get many false
positives or many false negatives.
Besides this, you assume all packages have an active upstream. Debian
contains several packages where the latest upstream release is e.g.
seven or ten years old. Your "advanced Debian-QA system" would
completely ignore such packages.
> Do you still want to call this: spamming to QA??
The main question isn't how to present the information (e.g. mails to
Debian QA or a web page).
The main question is:
How many people are actively working to resolve such issues?
Sending emails alone doesn't has any positive effect.
The opposite is often true:
The more mails go to a list, the more people unsubscribe due to the
traffic, and more important mails get unnoticed in the stream of mails.
> 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 is additional work required on two sides:
- the maintainers have to inform your system
- people have to go through the reports your system produces
> 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.
No problem with this, but in practice, I don't think it will be used
more than lintian.debian.org .
> 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.
There's no problem if you want to set up a web page, but if you want to
do QA work with the results, you need _much_ manual work at processing
the results of the web page.
> > > - 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.
>...
Automatic emails or bug reports don't gain you much - they tend to be
ignored by many maintainers.
> Friendly,
> Blu
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: