<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=28152) </details> <!--IssueSummary end--> [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. #### 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** - [ ] [Increase granularity of email notification settings](https://gitlab.com/gitlab-org/gitlab/-/issues/17572) #### 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. - [ ] [Include patch in Merge request notification](https://gitlab.com/gitlab-org/gitlab/-/issues/24205) #### 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: - [ ] [Think of a way to run Danger checks against MR from forks](https://gitlab.com/gitlab-org/gitlab/-/issues/23226) #### 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. - [ ] [Reply by Email - mbox/maildir support](https://gitlab.com/gitlab-org/gitlab/-/issues/14575) #### 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: - [ ] [LibreJS compatibility](https://gitlab.com/gitlab-org/gitlab/-/issues/15196) The use of reCAPTCHA is a F worthy for GNU ethical code hosting criteria: - [ ] [GitLab has a runtime dependency on a non-FOSS reCAPTCHA library provided by Google](https://gitlab.com/gitlab-org/gitlab/-/issues/21998) There are also a few incorrect naming of licenses: - [ ] [Ensure gitlab passes B2 of the GNU ethical repository criteria](https://gitlab.com/gitlab-org/gitlab/-/issues/15208) #### 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