Can we provide another UI for patches than just email ?

Can we provide another UI for patches than just email ?

[Edouard Klein]

Dear Guix,

I've just blown up Guix's debbugs by opening (and then closing) 33 bugs
instead of sending a 33-commits patch series.

I've also seen that there is a huge discussion on the cognitive overhead
of contributing. I will read it as soon as I can spare more time on this.

I find git email's workflow extremely frustrating and confusing. I know
it works for most of you who actually commit, but I would like to point
out that I'm one more person to be tripped by its complexity, and who
cares enough to say so here. There are probably even more people who
don't speak up.

Therefore, there is a huge cost in keeping up using it: less people will
be able to provide patches, and software will get stale.

For example, ou current Go version is 1.17 ! From 2021 ! The current is
1.21. I suspect that if contributing was easier, we wouldn't have a 2
years delay in our versions.

I do not want to open a flamewar about the merits of git email. I want
to point out that I personnaly find it difficult and that I'm not the
only one.

Now, do we want to address this as a community, and welcome developers
who may have good patches to contribute, but who can't spare at least ten
hours to get confortable with git email ?

An alternative solution would be to provide a public or semi-public git
remote, and just let people git push their branches there.

I suspect a git hook can then provide integration with debbugs if
necessary, and I would be willing to assist writing it.

In the current state, the UX is just unbearable, and I have in the past
(and likely will again) just not bothered sending patches because the
experience is so time consuming and infuriating.

Before anybody tries to explain to me that git send-email is easier than
I think, what you have to beat is:
git remote add guix-patches WHATEVER #only once
git push -u guix-patches master:some-unique-name

You can then push, pull, rebase, whatever, from the command line (or
magit in my case), without leaving your dev context. Can't be easier
than that.

Sorry about blowing up the debbugs. I'll do my best to avoid it in the
future.

Cheers,

Re: Can we provide another UI for patches than just email ?

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

> Dear Guix,
> 
> I've just blown up Guix's debbugs by opening (and then closing) 33 bugs
> instead of sending a 33-commits patch series.
> 
> I've also seen that there is a huge discussion on the cognitive overhead
> of contributing. I will read it as soon as I can spare more time on this.
> 
> I find git email's workflow extremely frustrating and confusing. I know
> it works for most of you who actually commit, but I would like to point
> out that I'm one more person to be tripped by its complexity, and who
> cares enough to say so here. There are probably even more people who
> don't speak up.

I have done that too, but I think the problem is caused by debbugs, not
by git send-email.

> Therefore, there is a huge cost in keeping up using it: less people will
> be able to provide patches, and software will get stale.
> 
> For example, ou current Go version is 1.17 ! From 2021 ! The current is
> 1.21. I suspect that if contributing was easier, we wouldn't have a 2
> years delay in our versions.

I don't think so, because we are already getting more contributions than
are getting reviewed. If contributions were easier to send but reviewing
them wouldn't change we'd just have that 2 years of delay in applying
the patches.

> [...]
>
> Before anybody tries to explain to me that git send-email is easier than
> I think, what you have to beat is:
> git remote add guix-patches WHATEVER #only once
> git push -u guix-patches master:some-unique-name
> 
> You can then push, pull, rebase, whatever, from the command line (or
> magit in my case), without leaving your dev context. Can't be easier
> than that.

It would be possible to have a git send-email -based workflow that would
look something like this:

$ git clone ...
[ make changes ]
$ git send-email origin/master
[ get feedback, edit and rebase ]
$ git send-email origin/master --in-reply-to=msgid
[ repeat ]

We could even have a script that would submit changes and with that the
workflow could be as simple as:

$ git clone ...
$ ./script new
[ make changes ]
$ ./script send
[ get feedback, edit and rebase ]
$ ./script send
[ repeat ]

The problem is not using email, it is that the tooling we currently have
or recommend requires doing more manual and error-prone steps than is
actually necessary.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Can we provide another UI for patches than just email ?

[Simon Tournier]

Hi Edouard,

It is very important to speak up, although that makes me sad to read
such poor feedback experience.

Well, the friction is about Debbugs.  Maybe I repeat myself: Debbugs is
initially thought to be a bug tracker system and not a patch track system.

Do not take me wrong, I am not trying to convince you.  Instead, I am
just trying to explain that email workflow is not so much different and
the main annoyances you point come from Debbugs and not emails,
somehow. :-)

On Thu, 14 Sep 2023 at 10:51, Edouard Klein <edou@rdklein.fr> wrote:

> Before anybody tries to explain to me that git send-email is easier than
> I think, what you have to beat is:

Well, the complete workflow you have in mind is:

1.  $ git remote add guix-patches WHATEVER              #only once
2.  $ git push -u guix-patches master:some-unique-name
3.  … send a Pull Request …                             #only once

Instead, the email workflow somehow reads:

a.  … send an Email to guix-patches@gnu.org             #only once
b.  $ git config sendemail.to 12345@debbugs.gnu.org     #only once
c.  $ git send-email --base=auto -v <N> origin

and the order is flipped:

        a == 3   #only once
        b == 1   #only once
        c == 2

Yeah, the order appears awkward. But that’s because of Debbugs; else it
would not be very different.

The advantage is that contributing does not require from you to have a
public Git repository, it requires from you only an email address.

The drawback (plural!), bah you already know them. :-)

Again, thank you for your feedback.

Cheers,
simon

Re: Can we provide another UI for patches than just email ?

[Edouard Klein]

Hi Simon, Saku

Thank you for your answers.

First, I should have slept on my email instead of sending it right away.
I was still dealing with the frustration of having made a fool of myself
with debbugs, which compounded with wrestling earlier with golang build
system. My tone was unnecessarily harsh, please accept my apologies for
that.

I'd like to be part of the solution, so Saku, I'd like to help
write the putative scripts you talk about. The main difficulty I see is
that they need to be configured to be able to send and receive email on
the user's behalf. I have some more patches to send over, I'll use that
as an excuse to see what I can come up with.



Second, I don't know what the general feeling is here towards debbugs, but
if moving away from it is something that may happen, my suggestion is not
to use anything with Pull Requests, as Simon you seem to have
understood. I worded my suggestion poorly. What I had in mind was a
(semi-)public-writable repo: code is pushed by developers, pulled and
reviewed by maintainers, and if satisfactory, rebased on to master.

If communication about the patch is needed, an email thread can be
started on the mailing list, CCing the commit author(s) whose email
address is known from the commits. A bash one liner starting with git
log ... | sed ... can create the email automatically from the proposed branch.

There is no need for any active code on the server, just SSH access or
maybe public git:// access, and a place to store the repos.
See
https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm?ref_type=heads#L526
the os/git function for an example on how to set that up on a guix
server.
See https://the-dam.org/docs/tutorials/git-hosting.html for how to set
it up and https://the-dam.org/docs/tutorials/private-git.html for how to
create repos once it is set up.

Details need to be ironed out, such as whether to make it world-writable
or to have a vetting process, whether to have a public-writable repo
segregated from the official one, etc. but I think a reasonable
configuration can be found. It seems simpler than git email with or
without debbugs, for both maintainers and reviewers, but I'll admit I
only have experience working with small teams, and not running a large
and successful open source project, so I can't be very assertive there.



Lastly, I think the lack of reviewers stems from the lack of
contributors. I for one feel like I could give good reviews on trivial
patches like new packages and package updates. Just check the repo is
the official one, check the licence is good, and check that it, and its
descendents, builds. I would gladly review a few packages a week, if I
did not dread interacting with git email. Again, not insurmontable, but
friction is a powerful thing.
If we could onboard contributors more easily, we would have a larger
pool of maintainers to pick from. Guix is freaking awesome, but very
hard to pick up. It took me a few years to get up to speed.



Anyway, thanks for the great software and for the time and guidance
y'all give on help-guix and here. Sorry for the ranty email.

Cheers,

Edouard.

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Edouard,
>
> It is very important to speak up, although that makes me sad to read
> such poor feedback experience.
>
> Well, the friction is about Debbugs.  Maybe I repeat myself: Debbugs is
> initially thought to be a bug tracker system and not a patch track system.
>
> Do not take me wrong, I am not trying to convince you.  Instead, I am
> just trying to explain that email workflow is not so much different and
> the main annoyances you point come from Debbugs and not emails,
> somehow. :-)
>
> On Thu, 14 Sep 2023 at 10:51, Edouard Klein <edou@rdklein.fr> wrote:
>
>> Before anybody tries to explain to me that git send-email is easier than
>> I think, what you have to beat is:
>
> Well, the complete workflow you have in mind is:
>
> 1.  $ git remote add guix-patches WHATEVER              #only once
> 2.  $ git push -u guix-patches master:some-unique-name
> 3.  … send a Pull Request …                             #only once
>
> Instead, the email workflow somehow reads:
>
> a.  … send an Email to guix-patches@gnu.org             #only once
> b.  $ git config sendemail.to 12345@debbugs.gnu.org     #only once
> c.  $ git send-email --base=auto -v <N> origin
>
> and the order is flipped:
>
>         a == 3   #only once
>         b == 1   #only once
>         c == 2
>
> Yeah, the order appears awkward. But that’s because of Debbugs; else it
> would not be very different.
>
> The advantage is that contributing does not require from you to have a
> public Git repository, it requires from you only an email address.
>
> The drawback (plural!), bah you already know them. :-)
>
> Again, thank you for your feedback.
>
> Cheers,
> simon

Re: Can we provide another UI for patches than just email ?

[Simon Tournier]

Hi Edouard,

On Thu, 14 Sep 2023 at 20:57, Edouard Klein <edou@rdklein.fr> wrote:

> Second, I don't know what the general feeling is here towards debbugs, but
> if moving away from it is something that may happen, my suggestion is not
> to use anything with Pull Requests, as Simon you seem to have
> understood.

People are discussing about hosting Sourcehut for managing the patches.
But it is still under discussion and AFAIK nothing concrete has
emerged.

>                                            What I had in mind was a
> (semi-)public-writable repo: code is pushed by developers, pulled and
> reviewed by maintainers, and if satisfactory, rebased on to master.

Well, I do not think what you are describing is pragmatically doable.

IMHO, the only option would be to use “git request-pull”.  Similarly as
you wrote in your first message, the contributor does:

     git remote add guix-patches WHATEVER #only once
     git push -u guix-patches master:some-unique-name

Instead of clicking on a button some web-forge requesting a pull, then
you send the kind of “pull request” by email.  First, you prepare the
cover-letter:

     git request-pull origin WHATEVER -p > cover-letter.txt

If you want, you can edit this cover-letter and add more comments if
needed.  Last, you send it – it would be nice to be able to send what
git-request-pull generates using git-send-email but I do not know how.
And one Debbugs issue will be open containing the patches and where to
pull.  And that’s all.

Hum, I do not know…

Cheers,
simon

Re: Can we provide another UI for patches than just email ?

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

> I'd like to be part of the solution, so Saku, I'd like to help
> write the putative scripts you talk about. The main difficulty I see is
> that they need to be configured to be able to send and receive email on
> the user's behalf.

That could probably be done via git send-email. I think the hardest
thing is working around debbugs. One idea I have is to first create a
branch with a name like <description>-not-submitted, then somehow get the
issue number after sending the first email and then rename the branch to
<description>-<issue-number> and either add a conditional git configuration
rule[1] that sets the sendemail-to to the corresponding address or use
that information from the script. Maybe mumi already does most of this,
I haven't tried it yet (but I probably should).

[1]: https://www.git-scm.com/docs/git-config#_conditional_includes

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Can we provide another UI for patches than just email ?

[Liliana Marie Prikler]

Hi Simon,

Am Donnerstag, dem 14.09.2023 um 19:48 +0200 schrieb Simon Tournier:
> a.  … send an Email to guix-patches@gnu.org             #only once
> b.  $ git config sendemail.to 12345@debbugs.gnu.org     #only once
> c.  $ git send-email --base=auto -v <N> origin
> 
> and the order is flipped:
> 
>         a == 3   #only once
>         b == 1   #only once
>         c == 2
I mean, the real benefit of git send-email is that these three steps
compress into a single one if you have a series that consists of a
single patch.  In fact, mumi send-email already implements this
workflow in a somewhat clunky way that works, but it requires the use
of yet another tool that isn't well known outside of Guix (at least
with git send-email you can point at how kernel devs do stuff).

Maybe we should actually fix that debbugs bug or advocate a separate
address that runs a script on the backend waiting for all emails to
land and then forwarding them to debbugs similar to what mumi send-
email already does.  I kinda understand that there are good reasons why
debbugs is not that smart out of the box (something something denial of
service), but for most reasonable cases it shouldn't take too long for
that cover letter to arrive even if the mails are out of order.  (Plus
we have moderation, so spamming of large series is kept to a reasonable
minimum already).  We could also implement a timeout solution like "if
it's a multi-patch series and the cover letter doesn't arrive within
five minutes of the first patch, send a mail to the contributor asking
them nicely to send that first and then wait a bit, and then abort the
process".  

Cheers

Re: Can we provide another UI for patches than just email ?

[Maxim Cournoyer]

Hi Saku,

Saku Laesvuori <saku@laesvuori.fi> writes:

>> I'd like to be part of the solution, so Saku, I'd like to help
>> write the putative scripts you talk about. The main difficulty I see is
>> that they need to be configured to be able to send and receive email on
>> the user's behalf.
>
> That could probably be done via git send-email. I think the hardest
> thing is working around debbugs. One idea I have is to first create a
> branch with a name like <description>-not-submitted, then somehow get the
> issue number after sending the first email and then rename the branch to
> <description>-<issue-number> and either add a conditional git configuration
> rule[1] that sets the sendemail-to to the corresponding address or use
> that information from the script. Maybe mumi already does most of this,
> I haven't tried it yet (but I probably should).

You should try out the mumi CLI command; it already knows to poll
Debbugs for the new issue when sending a multi-patch series, avoids the
manual task of manually sending the first patch, waiting, then sending
the rest to the newly created issue #.

-- 
Thanks,
Maxim

Re: Can we provide another UI for patches than just email ?

[Simon Tournier]

Hi Liliana,

On Sun, 17 Sep 2023 at 00:19, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

> Am Donnerstag, dem 14.09.2023 um 19:48 +0200 schrieb Simon Tournier:

>> a.  … send an Email to guix-patches@gnu.org             #only once
>> b.  $ git config sendemail.to 12345@debbugs.gnu.org     #only once
>> c.  $ git send-email --base=auto -v <N> origin
>> 
>> and the order is flipped:
>> 
>>         a == 3   #only once
>>         b == 1   #only once
>>         c == 2
>
> I mean, the real benefit of git send-email is that these three steps
> compress into a single one if you have a series that consists of a
> single patch.  In fact, mumi send-email already implements this
> workflow in a somewhat clunky way that works, but it requires the use
> of yet another tool that isn't well known outside of Guix (at least
> with git send-email you can point at how kernel devs do stuff).

I agree.  My explanations was trying to make clear, side by side, the
difference and similitude between the two main ways people are
exchanging code.  For sure, the PR model would be “inefficient” for the
“one single patch contribution” case.  If one would speak on the
concrete, one should do some stats about the number of patches per
contribution. ;-)

> Maybe we should actually fix that debbugs bug

IMHO, the issue is that Debbugs is out of the Guix project control but
run and administered by GNU folks (maintaining Savannah etc.).  Even, I
am not sure the exact version of Debbugs which is currently running is
publicly known; the current Debbugs version of the GNU instance diverged
from the Debian versions.

Last, I agree with the rest of your message. :-)

Cheers,
simon