> [Two mails previously] > Also the CI UI could use some improvements. I'm pretty sure I've > mentioned this before, but there is no easy way to find out which > inputs I need to fix to make a dependency failure disappear.
[...] That is precisely what the linear search algorithm is. I should not have to look through the dependency tree to figure out if two package failures have the same cause, or to know how many (possibly indirect) dependencies of a package are failing. As an example, pandoc often fails to build on i686, but when you look at the CI page, you see that it was caused by several of its inputs failing, all due to some of *their* dependencies. Now, you could dig down on one branch of the dependency DAG and find one failing package, but that doesn't *actually* answer the question: "what packages do I need to fix to enable this one?", because it could have multiple failing inputs instead of just one. The only way to tell is to look at each page, that means having to visually find each failing input on the page, wait for their CI pages to load, and repeat the whole process. If your browser is not particularly fast or you aren't so quick at navigating a webpage, this can take a while. But for the CI server, generating this information would take less than a second > Maybe some people value their time so little that they are fine with doing this the manual way, but personally I have better things to do.
ci.guix.gnu.org loads fast enough for me in my experience, but I do agree that more automation is good!
(I usually don't respond to e-mails I agree with except for superficialities, but I was wondering if such non-replies are actually interpreted as such, or as disagreements, or neither.)
Best regards, Maxime Devos.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
