Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

On 19.03.2019 9:45, Eli Zaretskii wrote:

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

Apologies for my choice of words (to Savannah admins especially), but 
the Savannah UI is mostly unused by everybody. And if we're talking 
about user accounts, they are very minimally used as well (e.g. they 
could have been be a part of the bug tracker UI). So what's left is a 
Git server, which is essential, but there are many other available 
alternatives.

Gitlab is a lot more comprehensive and thus unique in its functionality. 
And people are asking for it because of its UI, for the CI, the 
repository browsing, and the issue tracker.

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

I was also indirectly reacting to RMS's replies, I guess.

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

I think Konstantin was making a point that the PR workflow adds 
opportunities for a speed-up but doesn't take away anything.

And the email workflow would still be available for those who choose it. 
The mailing lists are unlikely to go away.

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

Of course not. Not every potential contributor anyway. Further, if I'm 
reviewing a random patch, *I* don't know if the contribution satisfies 
the CA requirements. If an automatic checking process were available, I 
could just respond with "Thanks!" and merge.

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

Hooks can help, but if Emacs doesn't even allow one to *commit* a 
change, it might discourage that person from continuing, or 
investigating the failed requirement. We can add too many checks to 
commit hooks.

Further, documentation could be in a separate commit, so we can't check 
for its presence when running hooks for a commit that adds a change.

And we can't check for copyright assignment inside a git hook because 
the information isn't publicly available.

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

I think the core message is sound. He said "easier", not "easy":

"""
migrating to gitlab should make contributions easier for bigger part of 
the open-source world, peoples who used to github and gitlab
"""

I agree with that.