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

[Maxim Cournoyer]

Hi Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> On 8/24/23 12:33 AM, ( wrote:
>
>>> * 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:
>
> I can envision some kind of upstream branch that's blessed and merged
> daily. The web crowd commits to that, the email crowd commits to main.
>
>> - 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.
>
> This isn't it at all, but I agree with your comment. I'm fond of
> email, and it's distressing how centralized it's become.
>
>> - 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
>
> It's this. Having to:
>
> 1. Remember the flags and their values
> 2. Remember the email address (it might seem silly unless you have
> forms of dyslexia. is it guix-patches? or patches-guix? Wait, what was
> I doing?)
> 3. And then the whole deal with what to do with follow ups.
>
> I feel like I know my way around git pretty well, but I struggle with
> how those concepts map onto sending emails.

Perhaps you'd like to invest 1 hour (30 minutes?) into learning to use
'patman'.  It allows attaching metadata to a feature branch by means of
Git message tags, e.g. the associated email address with 'Series-to:',
or the current revision with 'Series-version:', etc.  Then submitting
the series is a matter of invoking just 'patman', and following the
indications.

For more information, try: 'guix shell info-reader u-boot -- info
"(u-boot) Patman patch manager"'

> I have only been able to surmount this by lifting these concepts
> through scripts into higher-order concepts with less cognitive
> overhead.
>
>> - Switching between branches: The best way to handle this is with
>>    subtrees; see `git subtree --help`.
>
> Interesting! I use worktrees, but maybe subtrees are easier? I'll have
> to read up on this. Thank you!
>
>> - 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.
>
> I wrote some elisp to one-key apply patches from GNUS, but I guess my
> point is: not everyone can do that. How are we to expect more
> contributors if that, or something similar, is the barrier to entry?

Using an Emacs-based workflow:

1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
2. M-x cd RET ~/src/guix or wherever is your guix checkout
3. Select series you want to apply
4. Sort by subject
5. Press '|' (pipe) on any message, and pipe this to the command 'git am
-3'.  To apply multiple patches at once, you can specify an argument
prefix, e.g. 'C-u 10 |' to apply 10 patches at once.

I hope that helps someone.

-- 
Thanks,
Maxim