Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3140 bytes --]

> Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:
>> On 06-08-2022 08:55, Liliana Marie Prikler wrote:
>>
>>> +If your package has a bug that takes multiple lines to fix,
>> I don't think this is true for replacing all instances of "foo" by
>> "/gnu/store/.../bin/foo" in a file.
> Should it?
I don't think so. Directly substituting all the instances instead of 
first writing a patch that does "foo" -> "@foo@" or such seems simpler 
to me.  This might be a bit too nit-picky though, maybe it's clear from 
context that this is not the kind of fix meant by that line.
>>> + Furthermore, as with patches, modifying the snippets causes two
>>> derivations to be built.
>> This is true, but I don't think reviewers and package authors have to
>> worry about that.
> It does make a difference to the author when debugging their package.
> Starting with a phase and then moving it to a snippet can save good
> time.
Hm, maybe, I guess I often work on 'small' packages where it doesn't 
matter much.

On 09-08-2022 19:05, Liliana Marie Prikler wrote:
>>> +Such changes include, but are not limited to, fixes of the build
>>> +script(s) or embeddings of store paths (e.g. [...])
>>>
>> [...]
> Is that how to English comma?  Sorry, I'm not a native speaker so I get
> somewhat weirded out by the when to skip/not to skip rules.
>
Neither am I. English doesn't seem to do "rules" much. I do think, 
however, that adding a comma after "to" makes things a bit simpler to 
read here, and it doesn't appear to be ungrammatical -- at least, in 
licenses "but is/are not limited to" is often used that way.

> Derivations are a rather low-level concept, could they be avoided in
> the origin and phases documentation?
> I don't quite see how.  You could s/source derivation/the result of
> @code{guix build -S}/, but I don't think that's much better.
>
To be clear, do you mean you:

  * think it's not better, maybe even worse
  * think it's not _much_ better (but still _slightly_ better)
  * are undecided
  * or something else

?

Also, "guix build -S" returns the source code (after snippet / patch, if 
any), not its derivation. For the latter: "guix build -S -d"

>>> +Build phases are limited in that they do not modify the source
>>> +derivation.  Thus, they are inadequate for changes that are to be
>>> +reflected in the source code.  On the other hand, they only cause
>>> a
>>> +single rebuild and are thus slightly easier to debug than phases
>>> and
>>> +snippets.
>> See Andreas' comment on phase->snippet.
>>
>> Also, do I understand correctly that the argument here is that
>> 'single rebuild -> less compilation time -> easier to debug'?
> Easier to debug for the package author currently fiddling with the
> phase/snippet.  Not really a statement in any direction otherwise.
I don't see how "slightly easier to debug than phases" follows from 
"they cause only a single rebuild". My guess was that the intermediate 
step was lower compilation time, but apparently this was not the 
argument. As such, I'm not following.

Greetings,
Maxime.


[-- Attachment #1.1.1.2: Type: text/html, Size: 5441 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]