guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How can we decrease the cognitive overhead for contributors?


From: (
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Thu, 24 Aug 2023 07:33:32 +0100

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>     I signed up on Savannah with the intention of applying to be a committer.
>     Savannah closed my account one or two days later due to inactivity.

That happened to me, too :|

>     I can't ever seem to get the GNU style commit messages correct. I use the
>     templates provided, but those don't cover all cases, and I've even gotten
>     feedback in a review to change a message it created.

You do get used to it, but the format is very... verbose, and personally
I think we should abandon it; the signal:noise ratio isn't good, and I
don't think the automatic generation of ChangeLog files is a great idea
anyway, since so many changes to Guix are so trivial.  I think we should
just use the news file more often instead.

>     My script runs `guix style` and `guix lint`, but its suggestions aren't
>     always correct. I suspect I've submitted some patches with nonsensical
>     changes due to implicitly trusting these tools.

Yes, I'd personally advise against the use of `guix style` for now.
`guix lint` is fine, though.

> * Contributing to Guix is not for you

I'd hope nobody says this!  It's definitely not true, and rather
defeatist.

> * It's OK to make lots of mistakes

Yes. :)

> * We could support a managed web-based workflow

The problem with this is that it would not be possible without changing
the git hosting entirely to something like Gitea.  I'm personally a fan
of the email-based workflow; what, specifically, is it that bothers you
about it?  If it's:

- Setting it up: Yes, this is annoying.  Sadly, our mighty oligarchal
  masters have taken it upon themselves to make it as annoying as
  possible to use email from anywhere but their web or mobile clients.
- Sending the emails: This isn't that bad once you get used to it;
  sadly most Git clients (magit sadly included) don't support send-email
  well or at all.  But on the command line, all you need to do is:

  # for a single commit
  $ git send-email --to=guix-patches@gnu.org -1 --base=master -a
  # for several commits
  $ git send-email --to=guix-patches@gnu.org -$N_COMMITS --base=master 
--cover-letter -a

  Or, if sending an amended series:
  $ git send-email --to=$BUG_NUM@debbugs.gnu.org -$N_COMMITS --base=master -a 
-v$VERSION

- Switching between branches: The best way to handle this is with
  subtrees; see `git subtree --help`.
- Applying patches: This is a bit annoying.  Most email clients won't
  let you set up commands to pipe mailboxes to, unlike aerc.  Perhaps we
  could have a `mumi apply` command to fetch a patch series from debbugs
  and apply it to the checkout.

  -- (



reply via email to

[Prev in Thread] Current Thread [Next in Thread]