ng0 <n...@we.make.ritual.n0.is> skribis:
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -328,6 +328,21 @@ extensions---or to the operating system kernel---e.g.,
> reliance on
> @code{uname} or @file{/proc} files.
>
> @item
> +Run @command{guix refresh --list-dependent} (@pxref{Invoking guix refresh})
> +to find out how many packages would rebuild based on your patch.
> +When your patch touches important or a big number of packages, it is
> +prefered to be applied on the git branch core-updates or core-updates-next.
> +
> +@example
> +guix refresh -l libgcrypt
> +Building the following 822 packages would ensure 2221 dependent packages
> +are rebuilt:
> +@end example
> +
> +This is a good example for a number which indicates that a change to
> +libgcrypt would not simply be applied on master.
‘guix refresh -l’ is already mentioned in that section:
https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html
The specific branch names are not mentioned, but that’s also because
this process is still in flux. “core-updates” initially meant “updates
to the core”, where “core” designates GCC, libc, Binutils, and a few
other packages that make up the implicit inputs of gnu-build-system.
Python, libgcrypt, and similar packages are not “core” packages,
strictly speaking. Ideally, we’d run ‘python-updates’,
‘libgcrypt-updates’, etc. branches, but whether we do this depends on
our build farm capacity and on its current load.
In short, I think it’s best not too give too many details about a
process that’s not set in stone. :-)
Thoughts?
Ludo’.
