Re: Proposal: Build timers

[zimoun]

Hi Vagrant,

On Wed, 24 Nov 2021 at 12:23, Vagrant Cascadian <vagrant@debian.org> wrote:
> On 2021-11-24, zimoun wrote:

>> What if it takes 3h and the prediction says 2h?
>
> Those sound about "the same" for any kind of reasonable expectation...

Ah, we are not speaking about the same thing thus. :-)


> I would guess you only want the correct order of magnitude... hours,
> minutes, days, weeks, months, years... or maybe quick, fast, slow,
> painful.

Well, an order of magnitude is relative to an expectation.  My engineer
side is fine with a low expectation: it should take 2h and it
effectively takes 6h (probably unhappy) or the contrary it should take
6h and it effectively takes 2h (really happy).  My scientist side is
less fine about this poorly defined expectation.  Anyway! :-)

I think it is easier to set quick, fast, slow, courage based on timings
from Berlin.  Similarly with master, staging, core-updates which set a
rough number of packages for package impact, why not have:

 - fast: t < X
 - quick: X < t < 3X
 - fast: 3X < t < 6X
 - slow: 6X < t < 36X
 - courage: 36X < t

where X could be arbitrarily picked as 10min on Berlin or Bayfront.
This data could be exposed with the package, displayed by Cuirass or the
Data Service or the website [1].  Well, all require some work though.

(fast = less couples of minutes, quick = less than half-hour, fast =
less than hour, slow = less than six hours, courage = wait for it; the
reference is Bayfront or Berlin, with a clear hardware specifications =
number of core/thread, cpufreq and probably couple of other relevant
parameters)

1: <https://guix.gnu.org/en/packages/>


> I do this soft of fuzzy estimation all the time when working on
> Reproducible Builds in Debian; look at the past test history to get a
> *rough* estimate of how long I might expect a build to take. This helps
> me decide if I should start a build and get a $COFFEE, do some
> $SWORDFIGHTING on the $OFFICECHAIRS, or sit and watch the progress bar
> so I don't loose the mental state working on the problem becuase it will
> be done $SOON.

Yeah, me too. :-) I, more than often, do back-to-envelope computations
to estimate something.  From my point of view, there is a difference
between my personal estimation and a public official estimation.


> Make it clear it's an estimate, or maybe even abstract away the time
> units so that there is no expectation of any particular time.

I agree.  My point is: if the estimation providing a (even rough)
duration is not accurate enough, then it is not trusted (by user), i.e.,
not used; and all the effort does not worth it, IMHO.

Let back this claim by the example of ’relevance’ from «guix
search». :-) Because the accuracy, regarding the user expectations from
a query, is highly variable, the major behaviour I see is: iteration
over “guix package -A | grep” trying various package name.


Cheers,
simon