emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]