Re: git guix checkout automation for contributors

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Mon, 26 Sep 2022 at 22:37, Josselin Poiret <dev@jpoiret.xyz> wrote:

>> When running “guix time-machine” (inferiors), all the machinery
>> “./bootstrap && ./configure --localstatevar=/var && make” is
>> transparently done.  We discussed that at the 10 Years event with
>> Josselin.
>
> Yes!  Although FTR none of bootstrap, configure or make are actually run
> when using time-machine, it's a totally different way of building :).

Yeah, I simplified since it is somehow a detail. :-) Interested reader
can read Josselin’s explanations [1] about the differences.

1: <https://yhetil.org/guix/87let6roxo.fsf@jpoiret.xyz>

> The upshot is that we could even provide a flag like `guix time-machine
> --issue=NNNNN` that would provide the corresponding guix branch at
> https://git.guix-patches.cbaines.net/guix-patches/, and benefit from the
> built substitutes if there are.  It would need some more formal URL and
> discussion around this feature, but everything's in place for it to
> happen.

Well, I think it would be better to have another subcommand.  There is a
“guix review” draft somewhere but I do not currently find it.

It could be nice to see if it already just work using ’guix time-machine
-C channels.scm’ where the file channels.scm points to some QA.


>> Therefore, we could imagine something similar for helping people to
>> contribute:
>>
>>  1. use (test?) unmerged patches
>>  2. update and/or create new patches
>
> I think the second part would need a bit of work though, refer to Chris'
> mail [1] for what would need to be done (namely, making `git send-email`
> easier and refactoring the contribution guidelines).

I do not think git-send-email is the major roadblock here.  From what I
have seen two steps appear more difficult for infrequent contributors:

 a) commit message
 b) correct format-patch

About a) it could be nice to have a tool roughly checking.  For
instance, we have Emacs yasnippets for adding packages; we could imagine
a tool that check is the commit message respect some standards; at least
help to detect many common “mistakes“.

About b), from the feedback I get, people used to Merge/Pull Request do
not get at first why this step is required; since they usually git-pull
and send a request.  Then, many patches do not contain some base-commit
information because people miss the option --base; implicitly
self-contained with MR/PR.  Idem  the missing --reroll-count.


Cheers,
simon