summaryrefslogtreecommitdiffstats
path: root/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'TODO')
-rw-r--r--TODO34
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*