One of the side-threads in "Building a software toolchain that works" was essentially this:

If I fetch sources for a package using Guix, with the intention to make changes and then build and test the software myself, what should we do with any patches & snippets that are part of the Guix package?

There does not seem to be an obvious right answer. One reason is that patches and snippets fall into at least a few use cases:

- The upstream package won't build at all as-is using the environment Guix creates, so we apply a patch to enable a successful build.
- Upstream vendors some sources into their package, which we prefer to excise using a snippet so that we can do our own dependency management
- Upstream includes non-free components, which we remove to build a fully free package
- Upstream includes binaries in their package, which we prefer to snippet out so we can build them ourselves

At present we don't include any semantic information with each patch or snippet to explain why it is needed. Many have helpful comments; some don't.

Would it be feasible or desirable to create a set of "reason" symbols, similar to our "licenses," and attach a reason (or unknown?) to each snippet and patch? Then we can expose meaningful data to the end-user about patches & snippets that are available, enabling an informed choice about whether to apply them when fetching sources.

This could also be useful in our own record-keeping, so that we can track the usage of patches and snippets for different reasons. It would be nice, for example, to see a downward trend in the number of patches for build systems that won't work at all without them, either because we improve the logic in our build steps or because we contribute changes upstream to make software easier to build.