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

[Andreas Beckmann]

another random bit I just stumbled upon:

-          if (state == "failed-testing" and template[-9:] != "issue.tpl") \
-              or (state == "successfully-tested" and template[-9:] == "issue.tpl"):
+          if (state == "failed-testing" and problem.short_name[-5:] != "issue") \
+              or (state == "successfully-tested" and problem.short_name[-5:] == "issue"):

What's wrong with problem.short_name.endswith("issue") ?


maybe even worse:

  return( logpath[:-4] + KPR_EXT )



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


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

The primarily interesting one is 07 that should be integrated into
piuparts-report directly to avoid the .tpl intermediate step

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

The internal representation of a set of logs is very different
which makes integration into -report difficult

-report uses 
        logs_by_dir = {}
        for vdir in dirs:
            logs_by_dir[vdir] = find_files_with_suffix(vdir, ".log")


-report works with cwd=sectiondir that should make paths shorter and
less "difficult"

The assumption that there is only $pkgspec.log in (at most) one
subdir is nothing I would rely on (although it usually is)


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.


Andreas