From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 19:20:57 +1100 Message-ID: References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> <1552793646.5272.3@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004057e2058445f4b5" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="203498"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 09:23:46 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5R56-000qjm-VS for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 09:23:45 +0100 Original-Received: from localhost ([127.0.0.1]:51710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5R55-0005v2-UZ for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 04:23:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5R4r-0005s4-Rc for emacs-devel@gnu.org; Sun, 17 Mar 2019 04:23:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5R2g-0005lT-I0 for emacs-devel@gnu.org; Sun, 17 Mar 2019 04:21:18 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:39341) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h5R2e-0005k8-Me for emacs-devel@gnu.org; Sun, 17 Mar 2019 04:21:12 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id f10so4475291otb.6 for ; Sun, 17 Mar 2019 01:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tDNhoRWZJQpPgLzNNLIsEZsMf4ETPmKyVkzIBsolV4Y=; b=bL5PtiX+BYIov57WZKjpxrhp130VMCgWM0O466/SB1JY1pGDjuBdYbFkbSGp+lsArv XG3wdmaUdeF6l3bXSdhTWieEMXh1m4j7QhHUqYKRWv6idaISXdp5ocd4uPqnwRh8Z9HY 7G1KmhI3jfCF+PVayBqHbdia79CwZGLDOVpb8A0ad1cSirmCQgb5GeaDZpx1BsKvAKbS AtIECCq3USvTtcabkjUzqgDMOh3mjfuCn6+APuHNdfDKRajaNSj0+PW46fSPpFsyRyGy n0XHP4a46jj4NJRuULtV6VwGI1HG5pGoXqiQlgmlRqpKOA8uBYVclfhl6jDC08RpUVFp 70Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tDNhoRWZJQpPgLzNNLIsEZsMf4ETPmKyVkzIBsolV4Y=; b=PzDfjkW6U+/ejwIRFqqsX8lUF8ZYD3ywqDEpbjl5+z9ARhCDk+yJCZQtCmOJVFguRU ZVer0He8LnkSMO4zNXY6P9W0zmbWC2FBqR3tt4to0RthY5WyidToPixEY+h1C+Nup+MQ GjNnbcVJLDDSH5XiPETYfHZNelLwikWkadXGamPbgmOAuRDrJesdMGE/s7XpZ3OTkZd7 e5X2RhODay9uLAlY1NvQuaNQ2wJ56L/O8pU/aWMDZxPWLJiHQQcjzsV78BsNHbjln4yW 0d39Yjokfi7uxexEH+Hkm9IqlyO47+ukd268qRl2wIwtLuL8tHtRALjSDhZcQUe7uwAl jKvQ== X-Gm-Message-State: APjAAAVrAdkgEl7QTYxeegy+spKvlvYqNH/lLp1NjkFhqIh1Z5sqfqnD 9U1QPSY8MNOhWjKqxa/Db/fu6yhf08Rgsl2IGcJ5lXnt X-Google-Smtp-Source: APXvYqz3QXXsOM7PSdi5LRiJoK3Eg6zkl6VGeb8NyWllXpxdyDa+z7jdHJikoewhmK43g+3MfDJftzH2AxDKsRaVDxM= X-Received: by 2002:a9d:5f1a:: with SMTP id f26mr6837787oti.95.1552810869019; Sun, 17 Mar 2019 01:21:09 -0700 (PDT) In-Reply-To: <1552793646.5272.3@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::336 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234259 Archived-At: --0000000000004057e2058445f4b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Oops. Please, reply to this mail, I haven't thought that mails to > bugs-gnu gonna create new reports. Fixed here. > > =D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 6:01 =D0=94=D0=9F (AM= ), Konstantin Kharlamov > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > > > > > =D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 5:17 =D0=94=D0=9F (= AM), Konstantin Kharlamov > > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > >> 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."=C2=B9 > >> > >> 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=C2=B2. Gnome reports: "After switching to GitLab, I > >> noticed almost immediately an increase in contributions from people > >> I hadn=E2=80=99t met before. I think GitLab really lowered the thresh= old > >> for people getting started"=C2=B3. > >> > >> 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.=E2=81=B4 > >> 2. Gitlab makes addressing review comments easier. With mailing > >> lists workflow you either need to =CE=B1) send a v2 of the patch; whi= ch > >> 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 =CE=B2) 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=E2=81=B5 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.h= tml > >> 2: > >> > http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.h= tml > >> 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 > > > > > > > > > > --=20 regards, Tim -- Tim Cross --0000000000004057e2058445f4b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just for clarification, is your suggestion that <= a href=3D"http://savannah.gnu.org">savannah.gnu.org be changed to use G= itLab 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 requi= rements for contributions to GNU Emacs. I suspect this is one of the reason= s Emacs is not developed in a similar fashion to other projects which are b= ased on the use of pull requests etc.=C2=A0

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 perspecti= ve. The issue tracker is OK, but not sure it would meet the demands associa= ted with GNU Emacs. There are already existing Emacs wiki sites, so adding = another wiki is possibly of little benefit. Many of the other GitLab featur= es are likewise of marginal benefit given the specific nature of this proje= ct.=C2=A0

It would be a big job to migrate savannah.gnu.org to GitLab and you have th= e issue that despite the licensing, it isn't a GNU project, where I sus= pect all the interface etc on savannah is. I guess it would be for those wh= o maintain that system to evaluate and make the call. I'm not convinced= the effort would provide the benefits suggested. Reality is, those keen en= ough to complete the copyright assignment documents and commit to Emacs dev= elopment are unlikely to use any web interface - instead just using git on = the command line. The GitLab model works well where you have contributors w= ith more 'casual' connection to the project.=C2=A0

<= div class=3D"gmail_quote">
On Sun, 17 = Mar 2019 at 14:57, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
Oops. Please, reply to this mail, I haven't th= ought that mails to
bugs-gnu gonna create new reports. Fixed here.

=D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 6:01 =D0=94=D0=9F (AM),= Konstantin Kharlamov
<hi-angel@yandex= .ru> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
> =D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 5:17 =D0=94=D0=9F = (AM), Konstantin Kharlamov
> <hi-angel@y= andex.ru> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>> I want to start by answering first likely question: the Community =
>>=C2=A0 Edition of gitlab should be fine license-wise, quoting Richa= rd
>>=C2=A0 Stallman "We have a simple way of looking at these two = versions.
>> The=C2=A0 free version is free software, so it is ethical."= =C2=B9
>>
>> Terms: "merge request" in gitlab means "patch serie= s sent for
>> review".
>>
>> ----
>>
>> It makes me sad, seeing Emacs addons popping up, for a functional =
>>=C2=A0 that better could've been implemented in core. It's = a lot of
>>=C2=A0 contributors out there; at the same time, I see very little = patches
>>=C2=A0 on emacs-devel list.
>>
>> A lot of open-source projects already migrated to gitlab: all
>>=C2=A0 FreeDesktop projects, all Gnome projects; and KDE are likely= to
>>=C2=A0 migrate soon too=C2=B2. Gnome reports: "After switching= to GitLab, I
>>=C2=A0 noticed almost immediately an increase in contributions from= people
>> I=C2=A0 hadn=E2=80=99t met before. I think GitLab really lowered t= he threshold
>> for=C2=A0 people getting started"=C2=B3.
>>
>> So, at the very least, migrating to gitlab should make contributio= ns
>>=C2=A0 easier for bigger part of the open-source world, peoples who= used
>> to=C2=A0 github and gitlab. (btw, here's a rarely mentioned po= int, why in
>>=C2=A0 particular mailing-list workflow is hard for newcomers: almo= st
>> every=C2=A0 mail client out there breaks formatting by default; an= d
>> configuring=C2=A0 that out isn't always easy).
>>
>> Other points include:
>>=C2=A0 =C2=A0 =C2=A0 1. I know some people like to operate with mai= ls rather than
>>=C2=A0 web-interface (which is what usual gitlab workflow based on)= . For
>>=C2=A0 them gitlab can be configured to be managed with mails. I do= n't
>> know=C2=A0 how far it stretches, but at the very least creating/re= plying
>> to=C2=A0 issues/merge requests can be enabled.=E2=81=B4
>>=C2=A0 =C2=A0 =C2=A0 2. Gitlab makes addressing review comments eas= ier. With mailing
>>=C2=A0 lists workflow you either need to =CE=B1) send a v2 of the p= atch; which
>>=C2=A0 is a little frustrating: you need to find message-id to feed= it to
>>=C2=A0 git-send-email, and then you need to make sure its title lin= es up
>>=C2=A0 with the rest of the series. Or =CE=B2) resend whole patch-s= eries;
>> which=C2=A0 can be just redundant when all you did was a one-line = change,
>> and=C2=A0 clutters the mailing list. Also, upon sending v3, v4, et= c. you
>> need=C2=A0 to save somewhere changes since v1. You can put it in a= ctual
>> commits,=C2=A0 but for git-history this information is unnecessary= . With
>> gitlab=C2=A0 workflow, on the other hand, you just force-push chan= ges to
>> the=C2=A0 branch that has merge-request opened. A single command, = that it.
>>=C2=A0 =C2=A0 =C2=A0 3. CI. I've recently seen someone on emacs= -devel=E2=81=B5 asking a
>>=C2=A0 contributor to run their syntax-checking script on a regular= basis.
>>=C2=A0 That's becase you can't run any check on a code hang= ing out there
>> on=C2=A0 a mailing list in pure air. Gitlab supports CI, i.e. one = can set
>> it=C2=A0 up to run unit-tests for every merge-request created, so = these
>> errors=C2=A0 get caught before getting to the tree; and possibly e= ven
>> before=C2=A0 getting to eyes of reveiwers.
>>=C2=A0 =C2=A0 =C2=A0 4. Impossible to lose "merge request"= ;. I've seen in Emacs docs an
>>=C2=A0 advice to send patch series to a bugtracker, because on emac= s-devel
>>=C2=A0 they can easily be forgotten. That can't happen so easil= y with
>>=C2=A0 gitlab, where you have a tab with open merge requests.
>>=C2=A0 =C2=A0 =C2=A0 5. Discussion on patch series is easier to rea= d. On mailing lists
>>=C2=A0 can quickly appear a dozen of no longer relevant review mail= s, that
>>=C2=A0 refer to something that was addressed. In Gitlab the address= ed
>>=C2=A0 comments can be marked as such, and get collapsed.
>>=C2=A0 =C2=A0 =C2=A0 6. More tightly integrated bugtracker. When a = commit refers to an
>>=C2=A0 issue, it can be seen from inside the issue. This is useful = e.g.
>> when=C2=A0 someone fixed a problem, but for some reason couldn'= ;t address
>> review=C2=A0 comments, leaving the code behind. Then later peoples= who
>> stumble=C2=A0 upon the same issue can just improve the code instea= d of
>> doing=C2=A0 research and writing it on their own.
>>=C2=A0 =C2=A0 =C2=A0 7. Unclear how to download a patch-series from= mailing list.
>> Usually=C2=A0 mailing-list driven projects add some system that tr= acks
>> patches, and=C2=A0 allows to download series. E.g. that's how = Mesa
>> worked. But Emacs=C2=A0 don't seem to have one. With gitlab th= ough you
>> can simply fetch=C2=A0 someone's branch.
>>
>> 1:
>>=C2=A0 https://l= ists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
>> 2:
>>=C2=A0 http://kd= e.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
>> 3: https://www.gnome.org/news/20= 18/05/gnome-moves-to-gitlab-2/
>> 4: https://docs.gitlab.com/ee/= administration/incoming_email.html
>> 5:
>> http://lists.gnu.org/arc= hive/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

--0000000000004057e2058445f4b5--