[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gitlab Migration
From: |
Clément Pit-Claudel |
Subject: |
Re: Gitlab Migration |
Date: |
Thu, 26 Aug 2021 14:36:17 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
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.
(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.
- 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 and send or apply patches. 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. With Emacs patches we typically
ask the author to fix issues that are spotted by hand by a reviewer.
- 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.
- Re: Gitlab Migration, (continued)
Re: Gitlab Migration, john muhl, 2021/08/26
Re: Gitlab Migration, Daniel Martín, 2021/08/27
Re: Gitlab Migration, Tassilo Horn, 2021/08/27
Re: Gitlab Migration, Daniel Martín, 2021/08/27
Re: Gitlab Migration,
Clément Pit-Claudel <=
Re: Gitlab Migration, Dmitry Gutov, 2021/08/26
Re: Gitlab Migration, Eli Zaretskii, 2021/08/26
Re: Gitlab Migration, Dmitry Gutov, 2021/08/26
Re: Gitlab Migration, Stefan Monnier, 2021/08/26
Re: Gitlab Migration, tomas, 2021/08/27
Structured debbugs list per project (was: Gitlab Migration), Michael Albinus, 2021/08/27
Re: Structured debbugs list per project (was: Gitlab Migration), tomas, 2021/08/27