[Piuparts-devel] What are we optimizing for? (cf. dwke + -report)

[Dave Steele]

On Thu, Feb 21, 2013 at 2:55 PM, Andreas Beckmann <anbe at debian.org> wrote:
> Hi,
>
> what are our goals for overhauling detect_well_known_errors and
> piuparts-report?
>
> Dave aims at speeding up detect_well_known_errors. After having looked
> at the timings, I must say, I don't really care about this point right
> now. Generating .kpr from .log "just works" for me at the moment.
>
> I have usability problems (from a developer POV) with the known_problem
> report generation. Being scattered at the wrong places makes this hard
> to extend: .tpl generation in a shell script, problem list and ordering
> information hardcoded in piuparts report.
> Currently this is not easy to extend. Speed is only secondary.
>

My goals were to add rdep sorting to issues, and then later to
consolidate all known problem configuration into the conf files. Speed
improvement was at first an unexpected side effect, and then later a
strategy for slipping kpr generation into piuparts-report, leading to
conf file consolidation. The performance improvement patches can be
dropped without affecting functionality of the other commits.

The overall patch set solves the problems you list in the last
paragraph. The most significant blocker seems to be the kpr generation
time inside piuparts-report - a speed concern. That could be solved
with the "skip kpr generation" strategy I mentioned earlier (or
mitigated by your grep strategy).

Concerning what is currently in Holger's queue:

After our discussion, do you have any current concerns with
sort-issues-by-rdep, as a drop-in replacement for
detect_well_known_errors?

Given sort-issues-by-rdep, should sort-issues-by-rdep-fast be
considered as a stand-alone patch set?