Re: [RFE] Migration to gitlab

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7428 bytes --]

Just for clarification, is your suggestion that savannah.gnu.org be changed
to use GitLab instead of the current web interface or that GNU Emacs is
moved from savannah to a new home based on GitLab?

One thing I think you have possibly overlooked or glossed over is the
copyright requirements for contributions to GNU Emacs. I suspect this is
one of the reasons Emacs is not developed in a similar fashion to other
projects which are based on the use of pull requests etc.

GitLab is a good package. We use it to manage our projects and find it very
good. The CI and DevOps support is very useful for the types of projects we
do. For GNU Emacs, the CI stuff could be useful as a way to automate
running of test suites etc, but I can't see any benefit from the DevOps
perspective. The issue tracker is OK, but not sure it would meet the
demands associated with GNU Emacs. There are already existing Emacs wiki
sites, so adding another wiki is possibly of little benefit. Many of the
other GitLab features are likewise of marginal benefit given the specific
nature of this project.

It would be a big job to migrate savannah.gnu.org to GitLab and you have
the issue that despite the licensing, it isn't a GNU project, where I
suspect all the interface etc on savannah is. I guess it would be for those
who maintain that system to evaluate and make the call. I'm not convinced
the effort would provide the benefits suggested. Reality is, those keen
enough to complete the copyright assignment documents and commit to Emacs
development are unlikely to use any web interface - instead just using git
on the command line. The GitLab model works well where you have
contributors with more 'casual' connection to the project.

On Sun, 17 Mar 2019 at 14:57, Konstantin Kharlamov <hi-angel@yandex.ru>
wrote:

> Oops. Please, reply to this mail, I haven't thought that mails to
> bugs-gnu gonna create new reports. Fixed here.
>
> В Вс, мар 17, 2019 at 6:01 ДП (AM), Konstantin Kharlamov
> <hi-angel@yandex.ru> написал:
> >
> >
> > В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> > <hi-angel@yandex.ru> написал:
> >> I want to start by answering first likely question: the Community
> >>  Edition of gitlab should be fine license-wise, quoting Richard
> >>  Stallman "We have a simple way of looking at these two versions.
> >> The  free version is free software, so it is ethical."¹
> >>
> >> Terms: "merge request" in gitlab means "patch series sent for
> >> review".
> >>
> >> ----
> >>
> >> It makes me sad, seeing Emacs addons popping up, for a functional
> >>  that better could've been implemented in core. It's a lot of
> >>  contributors out there; at the same time, I see very little patches
> >>  on emacs-devel list.
> >>
> >> A lot of open-source projects already migrated to gitlab: all
> >>  FreeDesktop projects, all Gnome projects; and KDE are likely to
> >>  migrate soon too². Gnome reports: "After switching to GitLab, I
> >>  noticed almost immediately an increase in contributions from people
> >> I  hadn’t met before. I think GitLab really lowered the threshold
> >> for  people getting started"³.
> >>
> >> So, at the very least, migrating to gitlab should make contributions
> >>  easier for bigger part of the open-source world, peoples who used
> >> to  github and gitlab. (btw, here's a rarely mentioned point, why in
> >>  particular mailing-list workflow is hard for newcomers: almost
> >> every  mail client out there breaks formatting by default; and
> >> configuring  that out isn't always easy).
> >>
> >> Other points include:
> >>      1. I know some people like to operate with mails rather than
> >>  web-interface (which is what usual gitlab workflow based on). For
> >>  them gitlab can be configured to be managed with mails. I don't
> >> know  how far it stretches, but at the very least creating/replying
> >> to  issues/merge requests can be enabled.⁴
> >>      2. Gitlab makes addressing review comments easier. With mailing
> >>  lists workflow you either need to α) send a v2 of the patch; which
> >>  is a little frustrating: you need to find message-id to feed it to
> >>  git-send-email, and then you need to make sure its title lines up
> >>  with the rest of the series. Or β) resend whole patch-series;
> >> which  can be just redundant when all you did was a one-line change,
> >> and  clutters the mailing list. Also, upon sending v3, v4, etc. you
> >> need  to save somewhere changes since v1. You can put it in actual
> >> commits,  but for git-history this information is unnecessary. With
> >> gitlab  workflow, on the other hand, you just force-push changes to
> >> the  branch that has merge-request opened. A single command, that it.
> >>      3. CI. I've recently seen someone on emacs-devel⁵ asking a
> >>  contributor to run their syntax-checking script on a regular basis.
> >>  That's becase you can't run any check on a code hanging out there
> >> on  a mailing list in pure air. Gitlab supports CI, i.e. one can set
> >> it  up to run unit-tests for every merge-request created, so these
> >> errors  get caught before getting to the tree; and possibly even
> >> before  getting to eyes of reveiwers.
> >>      4. Impossible to lose "merge request". I've seen in Emacs docs an
> >>  advice to send patch series to a bugtracker, because on emacs-devel
> >>  they can easily be forgotten. That can't happen so easily with
> >>  gitlab, where you have a tab with open merge requests.
> >>      5. Discussion on patch series is easier to read. On mailing lists
> >>  can quickly appear a dozen of no longer relevant review mails, that
> >>  refer to something that was addressed. In Gitlab the addressed
> >>  comments can be marked as such, and get collapsed.
> >>      6. More tightly integrated bugtracker. When a commit refers to an
> >>  issue, it can be seen from inside the issue. This is useful e.g.
> >> when  someone fixed a problem, but for some reason couldn't address
> >> review  comments, leaving the code behind. Then later peoples who
> >> stumble  upon the same issue can just improve the code instead of
> >> doing  research and writing it on their own.
> >>      7. Unclear how to download a patch-series from mailing list.
> >> Usually  mailing-list driven projects add some system that tracks
> >> patches, and  allows to download series. E.g. that's how Mesa
> >> worked. But Emacs  don't seem to have one. With gitlab though you
> >> can simply fetch  someone's branch.
> >>
> >> 1:
> >>
> https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
> >> 2:
> >>
> http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
> >> 3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
> >> 4: https://docs.gitlab.com/ee/administration/incoming_email.html
> >> 5:
> >> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html
> >
> > Btw, one more point I just got: no more discrepancy between what
> > mailing list subscribers see, and what web-interface renders. E.g.
> > the nicely formatted list of points above from the outside worls
> > looks like a large single line:
> > http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html
> >
> >
> >
>
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 9833 bytes --]