Re: [RFE] Migration to gitlab

[Toon Claes]

Dmitry Gutov <address@hidden> writes:

> I fear it's a bit premature, considering we've not worked out the
> minimum requirements between ourselves yet, and Eli has not approved
> even minimal steps toward moving to GitLab.

I know Eli didn't approve. This issue is an exploration of the features
required. I totally respect Eli's opinion, and I'm happy he has a
critical look at it.

> Asking somebody from "outside" to read through our mailing list
> threads and make their own conclusions might be asking for
> trouble. :-)

I totally agree, so I spent my evening digging through this whole thread
again. I've updated the issue at
https://gitlab.com/gitlab-org/gitlab-ce/issues/60684

Let me also include the full body of it below, making it easier for
people to comment on it.

One more thing, I'm working at GitLab, so I might sound biased
here. Sorry about that, but I'm a heavy Emacs user too and I'm
passionate about both projects.


-- Toon

====================

[discussion](https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html)
on the emacs-devel mailing list was started to propose migrating the
development process to GitLab. This issue summarizes what would be
required to make that happen. A full migration might never happen, but
a GitLab workflow might be added to the existing mailing list
workflow. There is no decision made whether a migration to GitLab will
ever happen, this is just an exploration of the required and available
features.

This issue only focuses on GitLab, although there might be other
contestants like SourceHut:
https://lists.gnu.org/r/guile-devel/2019-01/msg00027.html

### Motivation

It would be nice if the Emacs community could attract more people to
the source code of Emacs itself. There are a lot of loose packages
created, which could belong to Emacs core. But Emacs development
workflow is "less modern" and that makes it harder for first-time
contributors to submit patches to Emacs core. Using a "more modern"
workflow, which GitLab provides, would lower the threshold for people
getting started.

### Requirements

#### Email workflow

Many people, including the main maintainers of Emacs, prefer a
mail-driven workflow. So however _first-timers_ contribute code, it
has to be compatible with the current mail workflow.

**Current state**

Users can configure their notification settings to get emails for
every issue create/comment addedd/merge request submitted to
GitLab. GitLab supports reply by email, so responses can be send back
directly from the MUA.

#### Submitting patches by email

Sending patches through email, and especially multiple versions of
changes, can be cumbersome. _first-timers_ should be able to submit
their changes to a Merge Request, and the system should be
automatically send out patch mails to a mailing list.

**Current state**

There is no need to squash your commits together to submit them to
GitLab. Because GitLab deals with branches, not with individual
commits.

It is possible to email patches to create a Merge Request:
https://docs.gitlab.com/ee/user/project/merge_requests/#adding-patches-when-creating-a-merge-request-via-e-mail

- [ ] GitLab does not support mailing a new version of the same
      patches

#### Reviewing patches by email

When patches are sent through email, it's easy to reply to them and
inline the comments at the lines the comments apply.

**Current state**

- [ ] GitLab does not support inline comments by email.

#### Merge request creation

It would be preferred if it's not needed to visit the Web UI to create
a Merge Request. Doing everything from the command line is preferred.

**Current state**

It is possible to create a Merge Request upon submit. See the push
options in the GitLab Docs:

https://docs.gitlab.com/ce/user/project/merge_requests/#git-push-options
 
#### Code should be companioned by documentation

Code submission should include documentation.

**Current state**

This is hard to automate, most projects on GitLab or GitHub address
this issue by having a template for Merge Request (or Pull
Requests). It should make contributors aware of ever step they need to
take make the contribution complete.

#### Formatting code commits

Commits should follow a certain formatting.

**Current state**

https://danger.systems/ is a tool often used for this. And it
integrates with GitLab. Although there is still an issue to use Danger
with forks:

- [ ] https://gitlab.com/gitlab-org/gitlab-ce/issues/49134

#### Diff mailing list

At the moment Emacs has a mailing list which generates an email for
every change that is submitted to the git repo. See
https://lists.gnu.org/archive/html/emacs-diffs

#### Traceability of Merge Requests

It should be _hard_ to have Merge Requests vanish and become lost in
history.

**Current state**

On GitLab Merge Requests are normally never deleted. It's very easy to
see which Merge Requests aren't merged yet. You can sort them by date
etc.

#### Continuous integration

Having tests run automatically and make it easy for _first-timers_ to
see the results would mimize the hassle to run automatic checks.

**Current state**

This is a core feature of GitLab. https://emba.gnu.org is already set
up, and tests are running. So this is 90% done. There recently has
been some instabilities with the results and these should be
resolved, see:
https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00968.html

#### Closely integrated bugtracker

Emacs development uses git and https://debbugs.gnu.org. These two
aren't closely coupled. Whenever a patch for a bug is submitted, it
requires manual steps to also close the bug report.

Emacs has `M-x` `gnus-read-ephemeral-emacs-bug-group` to fetch a
thread on a bug and allows you to respond to it. Or you can download
messages in `mbox` format.

**Current state**

Using GitLab Issues for bug reports will make it easier to have a
relation between submitted changes and bug reports. There are severals
way to link a Merge Request to an Issue, see:
https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge-request

In GitLab it's also easy to jump in an ongoing discussion on an
existing issue. It does not require looking the `Message-Id` and
manually adding people to `To:`, just add a comment to the issue, and
an email will end up at everyone involved.

- [ ] Export to mbox/maildir is not yet supported
      https://gitlab.com/gitlab-org/gitlab-ce/issues/19524

#### Spell & grammar checking

The documentation should follow the spelling and grammar rules
(e.g. two spaces between sentences).

**Current state**

With a little bit of configuration this is something CI can do. Well
not completely, but it can help. Manually proofreading still would be
required, with any system used.

#### Branch rules

In the workflow it matter to which branch changes are submitted to.

**Current state**

GitLab can have protected branches, and it can enforce some
limitations on those branches. But it still might require checking by
a human whether things are pushed to the correct branch.

#### Copyright assignments

Emacs requires legal paperwork for _larger_ contributions. Having a
built-in method to check if the contributor did take all the legal
actions to contribute can improve the contribution process. But it's a
hard problem, cause privacy has to be ensured.

**Current state**

Only users that are member of the project on GitLab would be allowed
to push branches to the canonical repository. Users who don't have
access can fork the project and submit their branch to that project
and create Merge Request to the canonical repo from their
project. It's a wide-adopted workflow on GitHub, GitLab, BitBucket,
etc.

#### Licensing

The system used has to be Free software.

**Current state**

GitLab CE is published under MIT/Expat license. It's not one of the
preferred licenses, but as far as I know, it's acceptable. Although
RMS did not agree
https://lists.gnu.org/r/emacs-devel/2019-03/msg00594.html, but that
applies to gitlab.com, I'm not sure that also would be true if a
GitLab installation was self-managed on FSF infra.

Also all the frontend Javascript code is free. Although it does not
yet properly report it's licenses to work with LibreJS:

- [ ] https://gitlab.com/gitlab-org/gitlab-ce/issues/15621

#### Integration with savannah

Emacs contributors have their account, SSH key, user rights configured
in https://savannah.gnu.org/. It would be great if the new system
would not require the creation of new accounts and access
rules. Keeping both systems in sync manually is destined to go wrong
at some point.

**Current state**

- [ ] Maybe integration with LDAP or SAML?

#### Integration with debbugs

It's easy to migrate the git repo, but the current database of bug
reports at https://debbugs.gnu.org also should be migrated.

**Current state**

- [ ] Would it be possible to export from debbugs to a CSV format the
      GitLab understands?
      https://docs.gitlab.com/ce/user/project/issues/csv_import.html

#### Emacs frontend for bug tracker

Emacs has a package for debbugs. This is a frontend that can be used
to find/create/update bugs on debbugs.gnu.org.

**Current state**

- [ ] Although GitLab has an API, there is no client for Emacs that
      works with it.
      
#### Bug reporting

Emacs has `M-x` `report-emacs-bug`. It's an awesome feature, but it's
fairly simple and just helps the user to format an email. From then it
uses the system configuration to send the email to the correct
address.

**Current state**

GitLab has a feature to Create Issue by Email, see:
https://docs.gitlab.com/ce/user/project/issues/create_new_issue.html#new-issue-via-email

signature.asc
Description: PGP signature