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

[Holger Levsen]

Hi,

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

> 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 
ones!


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