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

Holger Levsen holger at layer-acht.org
Sun Feb 24 15:52:23 UTC 2013


On Donnerstag, 21. Februar 2013, Andreas Beckmann wrote:
> 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 think his improvements in the fast branch are quite nice and we should use 

> 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.

Thats definitly also a goal to optimize for, and also the more important one 
I'd say.

> And we should probably group the failures "by phase" as the same error
> type can happen in different phases, and some may be more interesting
> and some just boring. Lets take as example a lenny->squeeze->wheezy test:

that sounds interesting.
> Any failure (e.g. postinst fails - that could happen at several places)
> before "distupgrade squeeze" would be rather boring for this test, as it
> will be the same failure as in lenny or lenny2squeeze and nothing we
> need to care about in l2s2w. But we can't just inherit all failures from
> lenny2squeeze: failing to remove/purge in l2s is nothing that can happen
> in l2s2w.

I'd not focus too much on the l2s2w upgrades, instead I'd focus on s2w now and 
w2j soon. Most (future) Debian users after all will be new users, not old 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20130224/ddb2d534/attachment.html>

More information about the Piuparts-devel mailing list