Re: Gitlab Migration

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 16:09:32 -0400
> 
> On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> > It's actually the other way around, at least in some cases.  With
> > patches that are emailed to me, I can fix some simple issues, such as
> > commit log messages or simple typos, myself, before applying.  With
> > merging via Web UI, I need to push another commit, which is a waste,
> > and also breaks what should have been a single commit into several
> > ones.  So with Web UI, I expect _more_ requests to contributors to get
> > their act together, where automated fixups are impossible, because
> > there's little I can do myself.
> 
> Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?

AFAIK, merging a PM is usually a UI action.  But if it is done
manually like you describe, then there's no difference, and no
advantage to either method.

> >> - 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 think you see problems where there are none.  If you have an email
> > message that belongs to a bug, reply to it; otherwise simply write to
> > the bug address.  admin/notes/bugtracker explains this within its
> > first dozen of lines.
> 
> This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document).

I've yet to see a serious project of reasonably large size and age
that didn't have such a document.  Coding conventions and patch
submission conventions vary among projects and change with time, and
keeping them unwritten is not a good idea.

> >> 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.
> > 
> > I realize that some people who want to contribute don't like emacs or
> > are intimidated by it. 
> 
> I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs.  Maybe I'm misunderstanding what you're saying.

I meant email.  Sometimes my fingers think they know better what I
mean.

> > That's an important reason to provide the UI
> > to which they are more accustomed.  But let's not exaggerate the
> > advantages of these platforms for the Emacs developers: though some
> > advantages exist, they are not that significant, at least IMO, and
> > there are disadvantages (described in the GitLab issue).
> 
> And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA).  That might suggest that even Emacs veterans see value in these online systems (?)

I didn't say there was no value, I said let's not exaggerate the
advantages.

And there's a difference between maintaining a project with perhaps
several Ks or several dozen Ks of lines, and maintaining Emacs.  With
Emacs we need all the power of the development environment
conveniently integrated in the same place; we need Emacs itself.