all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Vagrant Cascadian <vagrant@debian.org>,
	Julien Lepiller <julien@lepiller.eu>,
	Jacob Hrbek <kreyren@rixotstudio.cz>,
	Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Proposal: Build timers
Date: Wed, 24 Nov 2021 22:50:57 +0100	[thread overview]
Message-ID: <86h7c1te7y.fsf@gmail.com> (raw)
In-Reply-To: <875ysh5mmr.fsf@ponder>

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


  reply	other threads:[~2021-11-24 21:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 22:02 Proposal: Build timers Jacob Hrbek
2021-11-23  1:06 ` zimoun
2021-11-23  6:21   ` Jacob Hrbek
2021-11-23 11:56     ` zimoun
2021-11-23 14:39       ` Jacob Hrbek
2021-11-24 11:35         ` zimoun
2021-11-25  4:00           ` Jacob Hrbek
2021-11-23 12:05     ` Julien Lepiller
2021-11-23 16:23       ` zimoun
2021-11-23 20:09 ` Liliana Marie Prikler
2021-11-23 21:31   ` Jacob Hrbek
2021-11-23 21:35   ` Jacob Hrbek
2021-11-23 23:50     ` Julien Lepiller
2021-11-24 11:31       ` zimoun
2021-11-24 20:23         ` Vagrant Cascadian
2021-11-24 21:50           ` zimoun [this message]
2021-11-25  4:03           ` Jacob Hrbek
2021-11-25  5:21             ` Liliana Marie Prikler
2021-11-25 10:23             ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86h7c1te7y.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    --cc=kreyren@rixotstudio.cz \
    --cc=liliana.prikler@gmail.com \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.