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

[Vagrant Cascadian]

On 2023-09-03, Ricardo Wurmus wrote:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> In the simplest case, it can be as simple as:
>>
>> $ ./pre-inst-env guix refresh -u some-package
>> [build it, try it, fix if needed]
>> $ ./etc/committer.scm
>> $ git send-email
>>
>> Since it's a single patch, there's no jumping through hoops to create
>> the original issue, and the auto-configured git will CC teams people
>> subscribed to the scope of your change (if there are any).
>
> Sadly the not-so-simple case is much more annoying.
>
> I like an email-based workflow, don’t get me wrong.  At the same time
> I’m really not a fan of Debbugs.  It makes simple things more difficult
> than they should be (send a cover letter, wait for your mail to pass the
> anti-spam measures, remember that you wanted to send a couple of
> patches, etc), and no amount of sugar coating (whether that be a
> different frontend like Mumi or a hell of a lot of client-side
> scripting) can overcome this inherent clunkiness.

The only thing clunky about this particular aspect of the workflow
described is the fact that the guix community (maintainers?) have
decided on a one patch per mail policy with a cover letter, rather than
submitting the patches as attachments in the initial mail.

Debbugs may have numerous other ugly warts, but that is not really one
of them, in my opinion.

Changing that one policy (expectation?) would probably remove a
significant portion of the friction many people have with patch
submissions...

That change will likely have have other frictions, but I suspect they
would be much easier to adapt to...


> If only we can find a suitable baby sieve, I’d be happy to see the
> turbid bathwater drained.  If Mumi and Debbugs went down the drain to
> reveal a new hassle-free web/email hybrid patch workflow I’d be
> ecstatic.

I cannot complain about wanting the best of both worlds if the cost is
not too high. :)

For most of my work in Debian, I accept patches via bugs.debian.org (the
*original* debbugs instance, primarily email) or salsa.debian.org (a
gitlab instance, primarily web)...

Sometimes it is a little awkward because specific maintainers prefer one
interface over the other, or only pay attention to one or the
other... but for the most part I find it allows people to use whatever
works best for them...


At the end of the day git allows quite a few workflows, and the
submitters and committers do not even have to use the entirely same
workflow. There is plenty of room to be flexible.

I recently learned about and started using:

  https://git.guix-patches.cbaines.net/git/guix-patches

This allows me to pull the latest (usually!) patch submissions and
fiddle with and chew on offline... in the same way I might work with
most other git-based projects, merging and cherry-picking and doing
unmentionable things to those poor patches, all from the comfort of my
local machine. It suppliments the email workflow quite nicely, in my
opinion.


So, on the other end, if there was a central place where people (ideally
very open) could push patch submissions, so that people could more
easily pull them all at once, that might help alleviate some of the
issue from the other direction...


The fact that Guix code is largely a single git repository is something
I really value, and makes many things much easier... compared to Debian
which has largely one git respository per package, which might be hosted
on arbitrary servers, or maybe some other VCS, or maybe not even any VCS
at all (other than the Debian mirror itself)...


live well,
  vagrant

signature.asc
Description: PGP signature