GNU bug report logs - #75981
[PATCH (WIP) v1 0/4] Add 'guix fork'.

Previous Next

Full log

View this message in rfc822 format

From: 45mg <45mg.writes <at> gmail.com>
To: 75981 <at> debbugs.gnu.org
Cc: Nicolas Graves <ngraves <at> ngraves.fr>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Simon Tournier <zimon.toutoune <at> gmail.com>, Tomas Volf <~@wolfsden.cz>, 45mg <45mg.writes <at> gmail.com>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>, Ricardo Wurmus <rekado <at> elephly.net>, Attila Lendvai <attila <at> lendvai.name>, Simon Streit <simon <at> netpanic.org>
Subject: [bug#75981] [PATCH (WIP) v1.5 0/4] Add 'guix fork'.
Date: Wed, 05 Feb 2025 03:21:52 +0000

Hi all,

First of all, thanks to Maxim for the patch review! There are a lot of
things that I'll need to address in there. And thanks to everyone else
who's replied here. It's encouraging to see that people are paying
attention to my work; I was worried there wouldn't be enough people who
care about this issue.

So far, my approach to Guix stuff in general has been to just dive in
and work on things until they're done. But there's just so much work
here that if I dive in right now, I don't know when I'll resurface. And
I'm way too busy for that right now.

So, rather than doing a typical inline reply to each message in this
thread, I'm going to try to list out all the feedback I've gotten, and
everything that's pending. Then I'll talk about how I plan to work on
it. Feel free to comment on anything here.

I will try to organize the feedback I've gotten so far below:

1. The argument that this doesn't belong upstream. The main arguments
   seem to be that we should improve the review process instead, or that
   channels are sufficient for anything you'd use a fork for.
2. Feature suggestions:
   a. If the user has commit access, then allow them to use a merge
      rather than rebase upstream commits.
      I hadn't thought of this before because I was thinking entirely
      from a non-committer's perspective. But I guess even committers
      might want a personal authenticated fork in some cases. As Attila
      pointed out, some things may be rejected from upstream and some
      may be temporary kludges to get things working until you can
      implement a proper solution.
3. Larger code corrections - things I need to actually spend some
   thought on. Here's a list:
   a. I've used a mix of Guile-Git and just shelling out to the Git CLI.
      The idea behind this was to provide transparency about what the
      commands are doing. For example, we could implement a `--dry-run`
      option for `create` and `update` that will just output the git
      commands that will be run rather than executing them.
      With that said, however, there are some places where it would
      clearly be cleaner to use Guile-Git, and doing so would not make
      `--dry-run` output less useful. For example, the `git
      symbolic-ref` invocations to get branch names, etc. So I need to
      make some judgement calls in that regard.
   b. The use of the `#:argument-handler` keyword of
      `parse-command-line`. It's not clear to me how this would simplify
      things, and I need to put some thought into it.
   c. Error handling. Replacing `leave` with proper exceptions (in
      `openpgp-fingerprint*` and `guix-fork-update`), handling possible
      exceptions (from gpg in `openpgp-fingerprint*`). I'm not familiar
      with exceptions, etc. in Guile, and it'll take some time for me to
      figure things out.
   d. Whether `openpgp-fingerprint*` belongs in guix/channels.scm.
4. Minor code corrections, eg. formatting. These don't really need
   further discussion, and I can just address them sequentially as I
   work on the v2 of this patch series.
      
And here are the other things that are still pending:

5. Tests. These will be the first thing to work on, as it will likely
   speed up the development feedback loop a lot.
6. Implement `guix fork identify`.
7. Figure out how to make the existing git hooks 'fork-aware' -
   currently the post-merge hook runs where it shouldn't and fails,
   because it invokes `guix git authenticate` where it should be calling
   `guix fork authenticate`.
      
Now, on to the plan of action.

First of all, let's talk about '1.'. I think I may have addressed this
in the original thread, but going by the responses here, clearly I
didn't do so well enough.

Now, as Maxim pointed out, I will probably need to submit a GCD to get
this merged upstream. I think that would be the best place for me to
state my argument. That way, we can discuss whether this patch series
should be accepted at all, as well as the broader design - items '1.'
and '2.' from the list above - in a separate thread.

Simultaneously, we can use this thread for the concrete implementation -
items '3.' to '7.'.

That way, even when I don't have the time or energy to work on the code,
I can still keep the discussion going, and collect feedback and opinions
for when I do.

Thoughts? I've never had to juggle so much discussion and feedback with
implementation work like this (is this what a software career is going
to feel like?), so I'm open to suggestions here.

Thanks,
45mg

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.