[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFE] Migration to gitlab
Re: [RFE] Migration to gitlab
Tue, 23 Apr 2019 23:08:17 +0200
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
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.
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
This issue only focuses on GitLab, although there might be other
contestants like SourceHut:
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
#### 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.
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.
There is no need to squash your commits together to submit them to
GitLab. Because GitLab deals with branches, not with individual
It is possible to email patches to create a Merge Request:
- [ ] GitLab does not support mailing a new version of the same
#### 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. Doing 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 companioned 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
- [ ] 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
#### Traceability of Merge Requests
It should be _hard_ to have Merge Requests vanish and become lost in
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
#### 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.
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
#### 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.
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:
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
#### 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.
#### Branch rules
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.
#### 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.
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,
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.
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.
- [ ] 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
#### 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.
#### 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
GitLab has a feature to Create Issue by Email, see:
Description: PGP signature