Feature changed by: Glenn Doig (doiggl) Feature #306948, revision 7 Title: Estimation on waiting time on a package on obs Buildservice: Unconfirmed Priority Requester: Important Requested by: Glenn Doig (doiggl) Description: Hello, When your project is blocked in the queue because it is waiting for something to build e.g(binutils) can a time estimate be given as to how long to wait before it may start processing - put that estimation on the 'Package AAA (Project BBB home:CCC)' page when you view the page. Example: (Packages waiting queue * Average Job time) + (Your package Nth position in the Packages blocked queue * Average Job time ) = value Put that value in the package page. Some details used from https://build.opensuse.org/monitor It would be nice to know when your package may start to process. Cheers Glenn Responses so far sourced from http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00235.html
One could implement something, but it will not be very reliable, because the state and order can change with any further submission. > Adrian and I suggest to file a feature request using features.opensuse.org. But first:What to others think? Do you consider such an estimate ok? Or should we not publish anything since it might change too often? > Andreas
Discussion: #1: Stephan Binner (beineri) (2009-07-24 12:43:23) There is no "Nth position in blocked queue" and also no "Nth position in scheduled queue" as the scheduler randomly picks one out of it -> no estimation calculation possible. #2: Glenn Doig (doiggl) (2009-07-24 14:38:08) Another comment from http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00241.html From: Vincent Petry <PVince81@xxxxxxxx> Date: Fri, 24 Jul 2009 20:00:36 +0800 Message-id: <4A69A264.9020101@xxxxxxxx> Hi, I think it depends how much the estimation is wrong. If it says 10 minutes when it's 6 hours, I think it's not good. But if it says like 1 hour when it's 2, it might still be ok. At least it can help someone to decide whether it's worth waiting a few minutes/hours, or simply give up and check the next day. The time estimation for one package could be based on heuristics from its compile time history. For example, if after compliling a given package a few times we found out that it usually takes say 30 minutes to build successfully, then we can assume that in the future it will take almost as long, if not longer. Also like Doiggl said, it would be also good to know how many packages are in the queue. A value like "5234 packages scheduled to be built before yours, 1234 currently building" might do it. Vincent #3: Vincent Petry (pvince81) (2009-07-24 15:49:57) If the scheduler gets improved in the future, this estimation feature might be possible. #4: Glenn Doig (doiggl) (2009-07-30 05:01:35) Its impossible to tell where your job is, but your job is 'scheduled'. It would be nice to know where in the queue it is. I guess people would like to know where there job is in the 'blocked' que if your job is blocked. Host Arch x86_64 Packages in waiting queue 1027 Packages in blocked queue 15420 Average Job time 31 minutes + #5: Glenn Doig (doiggl) (2009-08-01 02:52:46) + some more info from -> + http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00302.html + Re: [opensuse-buildservice] BS monitor does not show all scheduled + jobs * From: <doiggl@xxxxxxxxxxxxxxxxxx> * Date: Fri, 31 Jul + 2009 19:39:22 +1000 * Message-id: + <674580bb0c949eff789615430df8ed36@xxxxxxxxxxxxxxxxxxxxxxx> Hello Thanks + Dominique, is there any possibility of utilizing the idle hosts to help + out even though it is a different platform e.g ppc64 [37 out of 197] + https://build.opensuse.org/monitor Cheers Glenn Dominique + wrote The only way to reduce the waiting time is throwing more + build power at it. If you have 200 packages, each taking 30 + minutes to compile, it's going to take 100 hours, no matter in what + order you build them. Except in the rare case that all packages are + waiting for a single build (example gcc). But then, this also won't + change, as it would block everything else, anyhow it's 'the only' + possibility to start with, as everything is blocked. So in + short: I guess to get shorter cycles, just more build hosts need + to be connected. (which of course summarizes down to somebody + needing to throw money in). A 'distributed' approach might be + interesting, but I understand that the question of trusting RPMs + built in such a way would be very very high up on the list (no + guarantee a remote worker is not tampering the created RPMs). + Dominique -- openSUSE Feature: https://features.opensuse.org/306948