unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philippe Vaucher <philippe.vaucher@gmail.com>
To: Konstantin Kharlamov <hi-angel@yandex.ru>
Cc: bug-gnu-emacs@gnu.org, emacs-devel <emacs-devel@gnu.org>
Subject: Re: [RFE] Migration to gitlab
Date: Sun, 17 Mar 2019 13:37:42 +0100	[thread overview]
Message-ID: <CAGK7Mr5M8Yb+-866S7QJ+ZgOUjJSWfwH8L2gXnfhmJiO=k6_Dw@mail.gmail.com> (raw)
In-Reply-To: <1552789070.5272.1@yandex.ru>

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

>
> 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"³.
>

I agree. I contribute often on github/gitlab, and the process is very
simple. In comparison, Emacs has hurdles that requires much more motivation
and persistance in order to contribute.

I think it boils down to this: on github/gitlab, almost everything is
handled by git itself: you propose/test changes by creating/pulling
branches on the repository/fork... so you basically only need to use git
and click a few buttons in the browser (or use magithub/emacs-gitlab etc).
With the Emacs model, you need to go back & forth between emails and git,
copying patches, applying them, keeping track of where each changes is,
etc. The extra step does not look like much but it is a lot, especially for
simple changes.



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

Yeah, the maintainer job is easier, no need to remember which topics are
the active ones. Searching for existing or past similar issues also feels
simpler, but I guess that is just habit.



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

It's also easier to view the current states of the commits, you don't need
to search for the latest patch in the list of emails.

Now, the Emacs model is similar to the linux kernel dev & the git dev
workflow, so obviously "it works fine" and has advantages too, but
personally I think those are outweighted by the the disadvantages (or
rather than the contribution experience is much nicer with gitlab).

Kind regards,
Philippe

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

      parent reply	other threads:[~2019-03-17 12:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-17  2:17 bug#34889: [RFE] Migration to gitlab Konstantin Kharlamov
2019-03-17  3:01 ` Konstantin Kharlamov
2019-03-17  3:34   ` bug#34889: " Konstantin Kharlamov
2019-03-17 16:48   ` Eric Abrahamsen
2019-03-17  3:39 ` bug#34889: " Eli Zaretskii
2019-03-17  4:04   ` Konstantin Kharlamov
2019-03-17 15:19     ` Eli Zaretskii
2019-03-17 12:37 ` Philippe Vaucher [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGK7Mr5M8Yb+-866S7QJ+ZgOUjJSWfwH8L2gXnfhmJiO=k6_Dw@mail.gmail.com' \
    --to=philippe.vaucher@gmail.com \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=hi-angel@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).