Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver <mhw@netris.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> Now, I would still like some guidelines for what to commit to master and what
>> to core-updates, that we could possibly write down in HACKING (and update when
>> the hydra situation changes). Does something like "If you modify PACKAGE from
>> base.scm, or 'guix refresh -l PACKAGE' shows that >= N packages are affected,
>> then commit to core-updates" make sense? If yes, what should be the value
>> of N? If not, what would be a better idea?
>
> I personally use ‘guix refresh -l’ as the metric to decide whether to
> create a branch or not.  I think it’s a good one though the ideal one
> would be makespan.  Another consideration is the current build farm
> load.
>
> The “Commit Access” section mentions “upgrades that trigger a lot of
> rebuilds”, which is quite vague but appeals to “common sense.”  I’m not
> sure this can usefully worded as strictly as you suggest.  WDYT?

I don't think we can decide on a value of N.  The decision should be
based not on the number of packages, but rather on the expected time
that users will be left without binary substitutes of the packages to
rebuild, how popular those packages are, how inconvenient it would be
for users to rebuild them on their own systems (e.g. icecat is very
popular and takes a long time to build), etc.

These considerations of the inconvenience to users should be compared
with the importance of the update/modification.  For example, security
updates warrant more inconvenience.  How much more depends on the
severity of the flaw.

I see no good way to formalize this.  I think we must rely on our best
judgment.

What do you think?

      Mark