[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Tue, 19 Mar 2019 16:13:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.

reply via email to

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