<div class="gmail_quote">On Mon, Feb 25, 2013 at 8:45 AM, Andreas Beckmann <span dir="ltr"><<a href="mailto:anbe@debian.org" target="_blank">anbe@debian.org</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In general I think we should allow the flexibility to have a per-section<br>
known-problems-directory setting, so each report Section should generate<br>
its own problem list and not get a global one passed<br>
<br></blockquote><div><br>OK, but out of scope of the patch set under consideration, which replaces the existing detect_well_known_errors with one that sorts by rdep.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I tried to create a reduced version of Dave's sort-issues-by-rdep branch<br>
that only does the .tpl generation, as that is the part I want to look<br>
at right now:<br>
<br>
preview/dave-dwke-only-create-tpl<br>
<br>
David Steele (9):<br>
01 Add skeleton for python replacement of detect-well-known-errors<br>
02 detect_well_known_errors.py - Clean obsolete kpr and bug files.<br>
03 detect_well_known_errors.py - Add class for handling known problems.<br>
05 detect_well_known_errors.py - Create missing kpr files.<br>
06 detect_well_known_errors.py - Create Failure Mgr class to hold kpr fails.<br>
07 detect_well_known_errors - Create html tpl files.<br>
16 detect_well_known_errors - Sort known errors/issues by rdep count.<br>
17 detect_well_known_errors - Display the reverse dependency count.<br>
20 detect_well_known_errors - Add PTS link to issue/error entries.<br>
<br>
reordered, merged, dropped .kpr creation, cleanup of obsolete files, ...<br>
but not tested at all<br>
<br></blockquote><div><br>Take a look at skip_kpr. It gives you your tpl-only capability with about a dozen lines of code. This is part of the piuparts-report work I originally submitted, which is out of scope for the patch set under consideration.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The problems I see right now:<br>
<br>
* many functions from piuparts-report are either copied<br>
(e.g. pts_subdir( source ))<br>
* or reimplemented differently, e.g. the variable substitution<br>
in the templates. I don't know which variant "is better", but<br>
I don't really want *two* implementations of the same thing<br>
<br></blockquote><div><br>This is not a change from what it replaces. Elimination of the redundancies can be added to the scope of a piuparts-report integration task.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The internal representation of a set of logs is very different<br>
which makes integration into -report difficult<br>
<br></blockquote><div><br>That depends on what you mean by integration. There is validity to the claim that it has been integrated, in existing patches outside the current scope.<br><br>As you are saying, if this was designed from scratch for integration with piuparts-report, it would lean much more heavily on packagesdb. What is on the table is not an integrated solution. It is a replacement for the bash script, with issue rdep sorting.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The assumption that there is only $pkgspec.log in (at most) one<br>
subdir is nothing I would rely on (although it usually is)<br>
<br></blockquote><div><br>It should be a valid assumption. The only requirement along these lines should be to avoid crashing in the presence of this error condition.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
BTS and PTS URLs should not be embedded in the templates, probably best<br>
to have a function that "generates" a certain url for a package name<br>
to allow for future "extensions", e.g. Ubuntu support.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>That is a change that is in scope with the future extensions. <br><br><br></div></div>I understand that you don't like the way that I solved the known_problem .conf issues in the patches that come after this submission, and that you believe they aren't the right way to add issues to piuparts-report. I am OK with you taking whatever pieces of this you might feel to be useful and crafting a more elegant integration. But I ask that you consider what's on the table within the scope of the problem it solves. Please make your changes for piuparts-report after this is in.<br>