Re: Gitlab Migration

[Arthur Miller]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 8/26/21 1:24 PM, Philip Kaludercic wrote:
>> Shouldn't it be easier to send an email than create an account, navigate
>> some web UI and fill in some form?
>
> I don't have strong opinions on mailing lists vs other approaches; but: no, 
> not necessarily.
>
> - Unlike email, a webform allows mistakes to be fixed easily (messages can be
> edited after being posted).  A mailing list does not allow this, so for
> newcomers the fear of "doing something wrong" is high.  Many projects have an
> issue reporting template now, and that can be nice.
I am an expert in having fingers faster than my brain. I found people here being
quite resonable when I send a second mail to correct my misstake.

You are a point there, it is easier to go back and fix errors, but that is about
the only one. I don't think that is so big deal to be a showstopper.

>   (Yes, emacs has M-x report-emacs-bug, but no, I haven't set up my Emacs to 
> send email yet, despite using Emacs for the last ten years).
>
> - Common actions can be mapped to buttons and dropdowns, making them more 
> easily
> discoverable. I don't interact with debbugs often enough to remember the
> commands, so I need to look them up every time I want to close a bug, tag an
> issue, etc.  In practice, I mostly leave these tasks to other volunteers.  
> With
> a web UI, I can apply tags from a list of known tags, close issues, mark
> duplicates, subscribe to an issue, etc. just by clicking my way around.  I can
> also trivially CC someone in a discussion (this is not easy with debbugs: you
> need to set up a custom header in your message, and mistakes can't be fixed by
> editing the original message).  It may be less efficient (although email isn't
> exactly fast), but it's very discoverable.
So you ask for a context menu for debbugs, that could be done?

> - State tracking can be easier.  The Gitlab UI has, at all times, the latest
> version of a patchset.  On the emacs mailing list, maintainers regularly 
> request
> a user to resent the latest version of a patchset, because changes can become
> hard to follow otherwise.
>
> - It requires less expertise with git and the patching workflow.  Committing 
> to
> "one branch per patch" means that contributors don't need to know how to
> prepare

That was something I had a thoughts about. Couldn't we have a command that
automate this, somethign like M-x create-patch-request. That could automatically
create a patch between current branch and master, and send it away, maybe prompt
user for an additional message.

>                             It also means that maintainers (or bots!) can push
> fixes directly, instead of requesting them.  For example recently I opened a
> pull request for a Python project I had never contributed to, and an automated
> system promptly pushed an additional commit to the branch to reformat my code
> using the project's preferred style.
Yes, but those things work only with things that are easily automated, such as
wha tyou mention, formatting the code. That can be automated with Emacs as well,
and I don't see reason why the patch author can't use Emacs formatting when
writing Emacs patch. I personally dislike gnu coding style, it is probably the
ugliest and most unreadable coding style I have ever seen, but how much pain
does it cause me to use it occasionally? Not much. I can live with that when I
work with Emacs sources.

> - Responding to old bugs is easier.  With a mailing list, it's no necessarily
> clear what the process is.  Should I send a new message to the bug address? Or
> does it need the right response headers?  In that case should I download the
> mbox first and import it into my email client?
>
> I'm sure there are many other pros and cons, but email isn't necessarily 
> particularly easy when you want to do more than send messages.

You are correct, but it is not particulary easy to use web interfaces en massé
either. I mean, people will clone repo to local disk anyway and code patch in
Emacs. Git can auto create patch. If one setups email account in Emacs, it is a
few clicks away to send patch to mailing list. It is more work to update your
repo on your gitlab account, than click on some button and fill some form to
send a PR.