Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Tue, 19 Mar 2019 02:52:17 +0200
> 
> On 17.03.2019 20:05, Eli Zaretskii wrote:
> >> savannah.gnu.org looks like a news site
> > 
> > Are you sure you are looking at the right page?  You should be looking
> > here:
> > 
> >    https://savannah.gnu.org/projects/emacs
> 
> I can't help but feel that the mentions of Savannah in this thread are 
> disingenuous.

I suggest you to look up the meaning of "disingenuous" before you use
it.  I don't think you really meant that.

In any case, you misunderstood my comment: it was in response to a
claim that Savannah looks like a news site, that's all.

> So since Savannah's role is very minor

See Glenn's response: that Savannah's job is largely behind the scenes
and under the hood doesn't mean its role is minor.  Quite the
contrary.

> >> I've just read a bit about that. I might be missing some nuances of the
> >> process, but right now I don't see how using merge requests vs emails
> >> could interfere.
> > 
> > It doesn't interfere, but it slows down the process for new
> > contributors, so doing this stuff quickly is no longer an attainable
> > goal.
> 
> Wouldn't the said contributors still be able to submit patches over 
> email anyway?

Again, this is orthogonal to what I was saying, as it takes my
comments out of their context.  The issue discussed was the alleged
speed-up of patch contribution process.

> On the other hand, the CI could check all the included commits in a PR 
> for their authors and the copyright assignments of each.  And GitLab 
> would show that this particular check failed, which could be more 
> accessible for a contributor than reading up on patch submission 
> conditions in the documentation.

Surely, each contributor already knows whether they do or don't have
assignment on file?

> >    . code submissions should include documentation
> >    . commit log messages should be formatted in a certain way
> >    . bug numbers should be referenced in log messages
> >    . US English conventions in writing comments and documentation
> >      (spelling, two spaces between sentences, etc.)
> >    . we require copyright assignments for accepting changesets larger
> >      than about 15 original source lines
> >    . we have peculiar rules regarding the branch were certain changes
> >      should be pushed (affects the branch against which contributors
> >      should prepare patches)
> >    . very elaborate coding and documenting conventions (their
> >      description takes around 900 lines in the ELisp manual)
> 
> At least some of these checks could be automated on a CI.

They can also be automated by Git commit hooks.  It's just a matter of
someone doing the job.

And I didn't say I was against adding CI to Emacs, that wasn't at all
the intent of my comments.  I just wanted to make the issue more
complete and balanced, because it isn't as clear-cut as the OP seemed
to indicate in the original message.