On 09-08-2022 20:58, david larsson wrote:
On 2022-08-05 15:59, Maxime Devos wrote:[..]20.4.5.3 Fixing technical issues (compilation errors, test failures, other bugs ...) Usually, a bug fix comes in the form of a patch copied from upstream or another distribution. In that case, simply adding the patch to the 'patches' field is the most convenient and usually does not cause any problems; there is no need to rewrite it as a snippet or a phase. If no ready-made patch already exists, then choosing between a patch or a snippet is a matter of convenience. However, there are two things to keep in mind: First, when the fix is not Guix-specific, it is strongly desired to upstream the fix to avoid the additional maintenance cost to Guix. As upstreams cannot accept a snippet, writing a patch can be a more efficient use of time. Secondly, if the fix of a technical issue embeds a store file name, then it has to be a phase. Otherwise, if a store file name was embedded in the source, the result of 'guix build --source' would be unusable on non-Guix systems and likely also unusable on Guix systems of another architecture.There may be other reasons to add patches: [...]
Agreed (*), but I don't think that subsection claims those are the only reasons for patches -- that section is only about fixing technical issues, not adding new features, as implied by the name of the section.
I can look at adding a new subsection 'Adding new functionality' for a v3.Liliana's documentation contains some information not in my v2, I intend to look into integrating that information as well.
1. Functionality, that is not yet accepted upstream, because maintainer(s) do not have enough time to review all pull requests, or are simply slow to review. "if no response within X time from upstream, then guix may include your patch" might be a good policy here.
(*) We sometimes do such things already. Example: <https://issues.guix.gnu.org/49828> (nowadays upstreamed). I don't think this thread is a good place for deciding on the exact rules though -- deciding on an appropriate value of X seems difficult, I would like to separate that from the current documentation patch.
Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
