Skip to content
GitLab
Next
Open
Issue created by Toon Claes@toonMaintainer0 of 13 checklist items completed0/13 checklist items

Feature requests that would allow GNU Emacs development to migrate to GitLab

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

Reduce email noise

While email is important, the content and amount of emails should be strictly relevant. Noise about labels are applied/removed, assignees are added/removed, etc. are not welcome.

Current state

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

Offline review

When a contributor sends a new version of their patches, the maintainer can fetch those patches from their email server, and review them offline, whenever they like.

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. Having the option to do 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 accompanied 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:

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

Current state

  • GitLab does not offer a notification stream of all submitted commits.

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

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:

The use of reCAPTCHA is a F worthy for GNU ethical code hosting criteria:

There are also a few incorrect naming of licenses:

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

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

Edited by Toon Claes