Requirements to migrate GNU Emacs development 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
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.
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.
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.
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.
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
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.
- 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.
It is possible to create a Merge Request upon submit. See the push options in the GitLab Docs:
Code should be accompanied by documentation
Code submission should include documentation.
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.
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
- 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.
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.
Having tests run automatically and make it easy for first-timers to see the results would mimize the hassle to run automatic checks.
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.
gnus-read-ephemeral-emacs-bug-group to fetch a
thread on a bug and allows you to respond to it. Or you can download
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
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).
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.
In the workflow it matter to which branch changes are submitted to.
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.
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.
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.
The system used has to be Free software.
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.
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.
- 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.
- 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.
- Although GitLab has an API, there is no client for Emacs that works with it.
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
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