l...@gnu.org (Ludovic Courtès) writes: > Andreas Enge <andr...@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