Provide developers a means of seeing "estimated build times" for each package

[luhring]

Context

For the distro's maintainers and contributors, many of the commonplace tasks involve trying to build a package locally for one reason or another. Such tasks include patching CVEs, adjusting the build pipeline for a package, adjusting the contents of a package, and so on.

The time it takes to build a single package can vary substantially — from under a minute 🏎️ to several hours 😭, and everywhere in between.

Request

For a developer that knows they have a handful of tasks to accomplish, and who's trying to decide which task makes sense to tackle in the time they have available at that moment, it would be immensely helpful to know a rough estimate of the time it takes to build each package.

The benefit of having this information handy is that someone can differentiate between a task that they can expect to accomplish within the time they have available vs. not. For instance, this information could make the difference between someone who has an hour available patching 2 CVEs within the distro vs. not even coming close on patching 1 CVE.

I'm envisioning this estimate being represented as N minutes on a per melange (YAML) file basis.

e.g.:

./cosign.yaml -> 2 minutes
./kyverno.yaml -> 5 minutes
./nodejs-18.yaml -> 35 minutes
./openjdk-11.yaml -> 33 minutes

[luhring]

Another (less important but) interesting bit of information to track for each package is what the bottleneck(s) is/are.

We now have the ability to optionally run builds remotely via Kubernetes, thanks to @joshrwolf (or @imjasonh, I can't really tell......... 🤔 ).

In the spirit of having data that helps developers be more productive with their time, we could — for example — notate that CPU is the bottleneck for building nodejs-18. This would signal the developer that they might want to use a remote k8s build in this case.

[joshrwolf]

this feels like something the proposed metadata addition to melange would be a good place to start, maybe something like:

package:
  metadata:
    size: (s|m|l|xl)

these would be manually specified for now, but we could start by simply binning these into some t-shirt sizes and get more data driven with these as we progress

[luhring]

😢