[Piuparts-devel] dwke wishlist - global report of all failed logs

[Dave Steele]

On Wed, May 8, 2013 at 3:00 PM, Andreas Beckmann <anbe at debian.org> wrote:
> Hi Dave,
>
> you know the new dwke code better than I ... can you generate a global
> report of all fail (only fail, no bugged/affected) logs from all
> sections - sorted by time, newest on top ... that should make reporting
> new bugs easier. Right now I have to check too many pages ...
>
> Listing should contain
>
> * timestamp section package_version.log (PTS) (BTS) #bugs
>
> maybe a second line with a list of known problems that have failed on
> this log
>
> Thanks in advance!
>
> IIRC there is a bug about this already.
> Ideally the time stamp of first failure of that log should be used, so
> the package does not pop up to the top just after having been retested
> and failed again.
> But I have currently no easy solution how to preserve these timestamps,
> so for a start the current log timestamp must suffice.
>

I would go a bit further in terms of desirable capabilities along
these lines. I think that p.d.o is hampered by the lack of maintainer
pages that cover all sections. The same with source package summary
pages. In both of these cases, as well as yours, visibility into
testing history would be valuable (I don't believe that retest
visibility is very good right now (Hmm, gnome-gmail started passing
again yesterday-wonder why)).

Back when I was thinking in terms of piuparts-server/reporting
packages, vs piuparts-master/slave/common, the idea was to replace
master's piuparts-report with a log/results submission interface to a
reporting server. Results would be stored in a database, and log
histories archived. A web framework on top of this database plus
current Packages would be able to slice and dice the results any way
you wish.

Concerning the issue on the table:

dwke.py is not a perfect home for what you are asking. It is templated
on the previous shell script, and so doesn't have visibility beyond
the current section. I've noted that I believe dwke should be
eventually subsumed into piuparts-lib and piuparts-report - in the
long term, I wouldn't add significantly to its responsibilities.

The barebones version of this doesn't need dwke. piuparts-report by
itself can come close, based on htdocs section fail directory
listings. A compliant implementation involving dwke implies another
(dreaded) template file (this one persistent) and a class to support
it.

All in all it doesn't sound like a prescription for a clean review and
merge process. Are you sure about this?