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

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Tobias Geerinckx-Rice <me <at> tobias.gr>, Nicolas Graves <ngraves <at> ngraves.fr>, Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>, Tomas Volf <~@wolfsden.cz>, 45mg <45mg.writes <at> gmail.com>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>, 75981 <at> debbugs.gnu.org, Ricardo Wurmus <rekado <at> elephly.net>, Christopher Baines <guix <at> cbaines.net>, Attila Lendvai <attila <at> lendvai.name>, Ludovic Courtès <ludo <at> gnu.org>
Subject: [bug#75981] [PATCH (WIP) v1.5 1/4] Add 'guix fork create'.
Date: Tue, 04 Feb 2025 14:38:08 +0900

Hi Simon,

Simon Streit <simon <at> netpanic.org> writes:

> Hello Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> My first thought was similar to Liliana’s reply in the other issue
>> thread: putting lots of energy into making it convenient to fork Guix
>> instead of contributing to the review process (described as slow and
>> erratic, which appears to be the motivation here), appears
>> counter-productive.
>
> I am all for contributing to the review process.  It is only through
> recent discussions on this subject that I am forcing myself to be a bit
> more active within the community again.  Thanks for getting me back in.
> I am also at fault my self.  I have a personal channel running and the
> list is getting longer on patches that rather be submitted.

I didn't mean to make anyone feel bad for having a channel, just to
state that if someone wants to have an impact on the slow review
process, the direction should be contributing toward that goal by
providing more eyes and hands, not providing more tools to more
comfortably doing our own things in our sandbox without interacting.  So
I'm glad if the result was to nudge you toward joining the review party ;-).

> I am nowhere close to be a contributor (yet).  I simply don’t have time
> and resources to be more active at the moment.  At the same time I also
> don’t want to wait for months until certain patches – which have been
> submitted for review – are pushed upstream.

There's no hiding it: reviewing is a (very) time consuming process, and
is currently done by volunteers, so on their own limited time they
probably would rather use to hack on things that personally matter more
to them :-).  The more hands we throw at it, the less time individual
reviewers have to spend on it to keep the community happy and running
smoothly.

> I do keep patches running on top of local branches that are constantly
> being re-based from upstream.  While time consuming, it seems to be the
> most convenient at the moment.

> I don’t even want maintain a local fork.  It is not that I really need
> one.  I use it for development, thus many branches are just dead ends
> that are kept for archival reasons.  I have a local central repository
> where I usually push my work to be more independent from my devices –
> which is my issue.  And here I only recently realised that I can’t even
> push these branches to my central repository any more.

For development, I simply use git checkouts and force-push them around
when I have to, or use './pre-inst-env guix deploy'.  It's not as
seamless as simply using 'guix', but it did the job when I needed it.  I
feel this feature here caters to more long-term forks that could have
multiple users, thus requiring authentication.

> Then I tried it the other day to set up a modified keyring and
> authenticate with my key and push it to my local repository as described
> in the manual.  I failed for some reason and probably missed something.
> This time I felt it: The bar is now seriously high to work on Guix at
> the moment.

I feel perhaps people are trying to replace Git by Guix :-).  Or are
operating outside what I'd call 'development', and want some
fancier/better integrated distribution means for Guix as a whole.

> While the authentication mechanism is useful and necessary to prove what
> is from Guix, it defeats the point to use Git as a decentralised tool.
> It should be possible to allow local modifications for personal use,
> also as unauthorised contributors.
>
> I am for it.  Including a warning that I am pulling an unauthenticated
> fork.

What do you mean unauthenticated?  The point of this feature is to make
authenticated forks easier to setup/work with, so you wouldn't get any
warning, unless I'm missing something.

Thanks for sharing your thoughts.

-- 
Maxim

Previous Next

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