From 3bf99c6f5662736b58fea9c4d7e2f49784acb4e8 Mon Sep 17 00:00:00 2001 From: Holger Levsen Date: Mon, 9 Mar 2015 20:21:11 +0100 Subject: minor cleanup --- TODO | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index c3181a10..d8d5fc1d 100644 --- a/TODO +++ b/TODO @@ -123,7 +123,9 @@ properties: ** information how many packages in other suites are in front of the first package in queue of this suite (so show a table of package, build_scheduled info and not just package names) ** information when new scheduling was done the last time for this suite * once experimental is fully tested, the scheduler should schedule 10% as many packages from experimental as from other suites, as all other suites are ten times as big -* graph average build duration by day +* more graphs +** graph average build duration by day +** graph oldest build age - in days * pkg sets related: ** new package set: kde/plasma @@ -141,15 +143,14 @@ properties: ** http://www.bstern.org/libuname/ - add "-ldl" to the linker flags... ** lunar suggests to use qemu with -r and -cpu and -rtc flags ** https://wiki.debian.org/qemubuilder - part of cowdancer - < Lunar^> I would rather say we do not do full uname and CPU variation that use an unreliable LD_PRELOAD - < Lunar^> because as soon as the package unset or reset the variable it won't be there anymore - * | h01ger nods. its also ok to leave some variations for when we go "for real" (aka rebuilds in the field) - | Lunar^: if that happens. if that doesnt we still get some more variations - | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete - | but we will find more problems "before going into the fields" - * | h01ger guesstimates that we would go from 300-600 builds per day to 100-200 with qemubuilder - | but those qemubuilders would only get 4 or 8gb ram... maybe 6. and that will have a huge impact - + < Lunar^> I would rather say we do not do full uname and CPU variation that use an unreliable LD_PRELOAD + < Lunar^> because as soon as the package unset or reset the variable it won't be there anymore + * | h01ger nods. its also ok to leave some variations for when we go "for real" (aka rebuilds in the field) + | Lunar^: if that happens. if that doesnt we still get some more variations + | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete + | but we will find more problems "before going into the fields" + * | h01ger guesstimates that we would go from 300-600 builds per day to 100-200 with qemubuilder + | but those qemubuilders would only get 4 or 8gb ram... maybe 6. and that will have a huge impact * misc ** show package status (briefly) on https://reproducible.debian.net/issues/*html @@ -158,16 +159,15 @@ properties: ** "fork" etc/schroot/default into etc/schroot/reproducible ** include no js header in the css ** use one css for all, not two minimally different ones -** graph oldest build age - in days ** restore the "find packages which have been removed from sid" part of reproducible_maintainance.sh ** re-enable the IRC notification for status changes, once the Pod::Man issue with timezone is fixed ** enable people to upload test packages, to be built in jenkins: - [17:27:51] h01ger: another wild future request by me: allowing us to upload something and let jenkins test it. rationale: I sent (another) patch for debian-keyring, to fix a timestamp issue in debian control files (due to not_using_dh-builddeb), but there is also a umask issue. I don't want to bother me to setup the very same things jenkins tests locally (I already did too much in this regards, imho), but really people can't tests everything - [17:27:51] jenkins tests. - [17:29:42] mapreri: please add the feature request to the todo. i'm thinking now that it maybe should just be a jenkins job not integrated into the rp.d.n webui, but... maybe we find a nice way to do it - [17:31:16] h01ger: I'm instead thinking about a repo defining a reproducible-specific suite or something on that line, that integrates well with the current setup. but this is really something wild. - [17:33:39] well, and everybody in debian-keyring from sid can uplood? :) - [17:34:37] that would be wonderful. + h01ger: another wild future request by me: allowing us to upload something and let jenkins test it. rationale: I sent (another) patch for debian-keyring, to fix a timestamp issue in debian control files (due to not_using_dh-builddeb), but there is also a umask issue. I don't want to bother me to setup the very same things jenkins tests locally (I already did too much in this regards, imho), but really people can't tests everything + jenkins tests. + mapreri: please add the feature request to the todo. i'm thinking now that it maybe should just be a jenkins job not integrated into the rp.d.n webui, but... maybe we find a nice way to do it + h01ger: I'm instead thinking about a repo defining a reproducible-specific suite or something on that line, that integrates well with the current setup. but this is really something wild. + well, and everybody in debian-keyring from sid can uplood? :) + that would be wonderful. === qa.debian.org* -- cgit v1.2.3-54-g00ecf