[Piuparts-devel] Bug#698526: Bug#698526: Sort known issues by reverse dependency count

[Dave Steele]

On Mon, Feb 25, 2013 at 8:45 AM, Andreas Beckmann <anbe at debian.org> wrote:


> In general I think we should allow the flexibility to have a per-section
> known-problems-directory setting, so each report Section should generate
> its own problem list and not get a global one passed
>
>
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.


>
> I tried to create a reduced version of Dave's sort-issues-by-rdep branch
> that only does the .tpl generation, as that is the part I want to look
> at right now:
>
> preview/dave-dwke-only-create-tpl
>
> David Steele (9):
>       01 Add skeleton for python replacement of detect-well-known-errors
>       02 detect_well_known_errors.py - Clean obsolete kpr and bug files.
>       03 detect_well_known_errors.py - Add class for handling known
> problems.
>       05 detect_well_known_errors.py - Create missing kpr files.
>       06 detect_well_known_errors.py - Create Failure Mgr class to hold
> kpr fails.
>       07 detect_well_known_errors - Create html tpl files.
>       16 detect_well_known_errors - Sort known errors/issues by rdep count.
>       17 detect_well_known_errors - Display the reverse dependency count.
>       20 detect_well_known_errors - Add PTS link to issue/error entries.
>
> reordered, merged, dropped .kpr creation, cleanup of obsolete files, ...
> but not tested at all
>
>
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.



> The problems I see right now:
>
> * many functions from piuparts-report are either copied
>  (e.g. pts_subdir( source ))
> * or reimplemented differently, e.g. the variable substitution
>   in the templates. I don't know which variant "is better", but
>   I don't really want *two* implementations of the same thing
>
>
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.



> The internal representation of a set of logs is very different
> which makes integration into -report difficult
>
>
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.

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.



> The assumption that there is only $pkgspec.log in (at most) one
> subdir is nothing I would rely on (although it usually is)
>
>
It should be a valid assumption. The only requirement along these lines
should be to avoid crashing in the presence of this error condition.



>
> BTS and PTS URLs should not be embedded in the templates, probably best
> to have a function that "generates" a certain url for a package name
> to allow for future "extensions", e.g. Ubuntu support.
>
>
That is a change that is in scope with the future extensions.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20130225/4d5c90f3/attachment.html>