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

[Andreas Beckmann]

On 2013-02-22 01:58, Dave Steele wrote:
> 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?

>+        or (ctime(logdict[pkgspec]) > ctime(cachedict[pkgspec])

You want os.path.getmtime() here. ctime is inode change (c=change, not
c=creation!) time, updated e.g. every time we hardlink the logfile to
htdocs/ or recycle/

You introduce two classes Problem (I'd probably call it KnownProblem)
and FailureManager, that should probably go to piupartslib/
And I would restrict the keys accepted while parsing a
known_problem.conf to a predefined list.

create_problem_list should probably be a library function, too
x.endswith(".conf") should be equivalent to and faster as
re.search('.conf$', x)

Problem.has_problem() should be postponed to a second commit.

And with these two classes it should be possible to generate the .tpl
inside piuparts-report (and write out the full page immediately), still
using the hardcoded list of problems found there ...
That should be easier because most of the infrastructure should already
be there.

Then we can just remove that part from the shell script. It's not a bash
script (as in it "requiring bash-specific extensions").

Adding rrdeps sorting at that point should be easy as well.

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

I'd prefer s/INCLUDE/PATTERN/ or s/INCLUDE/REGEX/
There is no need to generate an exact grep command line - just
presenting the pattern properly is enough. (And it should be usable for
grep -E.)

And rename the branch to something more descriptive like
parse-logfiles-with-python-re (but of course leave it on top of the
rrdep thingy)

Anyway, that should be the base for any improvements to logfile parsing.


Andreas