minor cleanup

1 files changed, 17 insertions, 17 deletions

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)
-		<h01ger> | Lunar^: if that happens. if that doesnt we still get some more variations
-		<h01ger> | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete
-		<h01ger> | 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
-		<h01ger> | 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)
+	<h01ger> | Lunar^: if that happens. if that doesnt we still get some more variations
+	<h01ger> | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete
+	<h01ger> | 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
+	<h01ger> | 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] <mapreri> 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] <mapreri> jenkins tests.
-		[17:29:42] <h01ger> 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] <mapreri> 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] <h01ger> well, and everybody in debian-keyring from sid can uplood? :)
-		[17:34:37] <mapreri> that would be wonderful.
+	<mapreri> 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 
+	<mapreri> jenkins tests.
+	<h01ger> 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
+	<mapreri> 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.
+	<h01ger> well, and everybody in debian-keyring from sid can uplood? :)
+	<mapreri> that would be wonderful.
 
 === qa.debian.org*