[Piuparts-devel] What are we optimizing for? (cf. dwke + -report)
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
> 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
> 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...
More information about the Piuparts-devel