From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 10 May 2019 19:37:31 +0900 Message-ID: <17D21056-10B2-4813-AE90-9B2706936CE9@icloud.com> References: <1552789070.5272.1@yandex.ru> <87imwhmmt8.fsf@gmail.com> <87y347g1l3.fsf@iotcl.com> <9ac21e82-8e47-f9b5-f88d-23c0c56946d1@yandex.ru> <87pnpc1lby.fsf@iotcl.com> <83zhoezdqc.fsf@gnu.org> <87imuivfcr.fsf@iotcl.com> <83k1eyfxls.fsf@gnu.org> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-22B7F91D-9A9C-4335-A3F4-9DB1EAD1563D Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103523"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Toon Claes , emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 12:37:54 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 1hP2uX-000QlE-QR for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 12:37:54 +0200 Original-Received: from localhost ([127.0.0.1]:40840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP2uW-0002b3-KG for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 06:37:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP2uK-0002X4-Mk for emacs-devel@gnu.org; Fri, 10 May 2019 06:37:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP2uI-0001iK-J3 for emacs-devel@gnu.org; Fri, 10 May 2019 06:37:40 -0400 Original-Received: from pv50p00im-ztbu10011701.me.com ([17.58.6.53]:39427) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hP2uI-0001h6-AI for emacs-devel@gnu.org; Fri, 10 May 2019 06:37:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557484657; bh=foSznydb99E9ZBdiMG1p6B3T7zrwLCxPXK/30Q2OwDw=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=z5O2eMCSx3n/VrAHXEQXMT3XHRk8SZ6ldpk6IKJohKZphaGOoadbmQYPydNiRojG2 Vrr5PWqNUBszNfRTNxaAqotjwDEI+4dQUF04icM+Zob4Ood9bin4qW3MhaapfvZaWO eP+pTFAZZW4445Ar57FWbk3rfmgAbCsXmcFgTdYzLQV8PpaoroIecjfxLORMMmcwdt 5JCyTJEieX3iBewpgVF0P3fvz4ikLyqagEz7mD3IKHb53BoROSTffyQ5RMkOgYhVUe uRCvkmRmhBlUi+LyGXG7n1uQ/eC5SAjD+MQLCBPqGBxMR1+UILCHkmykle+aryxc+z AeCctT1F+4x0w== Original-Received: from [10.199.120.22] (unknown [223.62.162.23]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id CC9B98A02A2; Fri, 10 May 2019 10:37:35 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <83k1eyfxls.fsf@gnu.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-09_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905100076 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.53 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:236360 Archived-At: --Apple-Mail-22B7F91D-9A9C-4335-A3F4-9DB1EAD1563D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, I have used both GitLab & Github, and my few cents: (I may have mixed up Github and Gitlab as I use Github much more than Gitlab= ; please fix me if I=E2=80=99m wrong) 2019. 5. 10. =EC=98=A4=ED=9B=84 6:49, Eli Zaretskii =EC=9E=91= =EC=84=B1: >> Let try to explain the contribution process on >> GitHub/GitLab/BitBucket/etc. briefly. >>=20 >> A contributor wants submit a change. >=20 > Note how you again start from a change, not from a report of some > issue/bug. As Emacs is a very old and stable project, most of our > changes fix bugs, not add new features. Therefore, use cases that > begin with issues are much more important to the workflow and to > assessing the utility of the tools. Any contributor can freely submit a pull request that has the word `Fixes #(= Issue number)` and when the pull request is accepted, the issue is automatic= ally closed. >>> because IMO many of the issues were described in exaggerated form >>=20 >> Exaggerated in which sense? >=20 > In the sense of representing various aspects of the current flow as > abysmally inadequate, and the proposed solutions as no less than a > panacea. Both workflows are inadequate, and overly complicated, but most people will b= e more familiar to the Gitlab Pull request workflow, and greatly lowers the b= ar for people who would like to contribute for the first time. >>> I don't like that, mainly because text editing facilities of a browser >>> are vastly inferior to what I'm used to expect from Emacs. >>=20 >> I understand. That's why I want to figure out whether we can add changes >> to GitLab, so (almost) everything also can be done outside the >> webbrowser, and from emacs. Or maybe build something like the debbugs >> package for emacs. >=20 > Personally, I think an Emacs client is almost a must, if we want to > consider something like GitLab seriously. There are many Emacs clients that tightly integrates with magit; I assume yo= u use magit for managing git repos?=20 The best one IMO is the official (magit) one: Release: https://emacsair.me/2018/12/19/forge-0.1/ Manula: https://magit.vc/manual/forge/ Repo: https://github.com/magit/forge I=E2=80=99m not sure if commenting on PRs are available; (I don=E2=80=99t us= e that feature particularly) but I regularly create issues/PRs and push them= , fetch them, etc... and notification is also available :-) It works with Github and Gitlab, and semi-supports Gitea and other forges. (The initial setup needs the web UI when using Gitlab though; as the Gitlab A= PI doesn=E2=80=99t support create a token unless Github.) >>> Discussing a bug report or a patch in a browser is thus inefficient >>> and quite frustrating, especially when advanced text editing and >>> processing is needed. A browser also takes me a step further from the >>> source code (you don't suggest that I use File->Open of the browser to >>> browse the code, right?). >>=20 >> Well, mention you mention a commit hash in your comments, the hash >> becomes clickable >=20 > I didn't mean the commit itself, I meant Emacs sources in general. I > frequently need to look up source fragments and definitions of various > macros and structs when I review a patch. Since the browser have no > idea where the sources are, and is not in general a good tool for > viewing sources of a software project, it is much less helpful here. With emacs(see magit/forge), this is not an issue anymore! :-) >> Probably the most complicated about the current bug tracker, at least >> from irregular contributor's POV, is interacting to a existing bug: >> Where do I send the email to? Who do I CC? How do I set In-Reply-To? >=20 > In any decent MUA (certainly with Emacs MUAs), this is almost trivial: > the defaults always DTRT. You don't need to think about any of that. >=20 >> On debbugs, I also always forget how to use the control server >> commands. >=20 > Having a need to use the control command is rare, so I don't think > this is a serious disadvantage. Besides, tricky control commands will > give you that with any tool. >=20 >> GitLab fixes that by showing buttons for actions like >> close/reopen/label/assign... >=20 > There are maybe 2 or 3 people in the Emacs project who use these > actions, so I'm not sure why we should be so interested in them. >=20 >> Yes, I tried to stress the importance of email too. I regret to hear the >> email interface of GitLab didn't work for you. I'll have a look whether >> I can suggest changes to make the "litter" configurable. But besides >> from that, are there any other annoyances you've encountered so far? >=20 > I don't know. If the email notifications can be configured to work > reasonably well, and could be responded to by email, that might be > enough to start a more serious evaluation of the workflow. As magit/forge supports viewing notifications about the repo in the magit in= terface; this is no longer an issue anymore. >>> And one more thing: Emacs is I think special in how we work as a >>> team. Most of the people who respond to bug report and review patches >>> have write access to the repository, and many of them are trusted to >>> push changes without approval. It sounds like Gitlab has a very >>> different team organization in mind, but maybe I'm mistaken. >>=20 >> GitLab shouldn't try to force you in some organisation structure >=20 > We'll need to explore this more, I think. It was my impression that > many defaults there were configured for a certain hierarchical > organization of the team, which is not what we have here. >=20 --Apple-Mail-22B7F91D-9A9C-4335-A3F4-9DB1EAD1563D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, I have used both GitLab & Github,= and my few cents:
(I may have mixed up Github and Gitlab as I use Githu= b much more than Gitlab; please fix me if I=E2=80=99m wrong)

2019. 5. 10. =EC=98=A4=ED=9B=84 6:49, Eli Zaretskii <eliz@gnu.org> =EC=9E=91=EC=84=B1:

<= blockquote type=3D"cite">Let try to explain the contribution process o= n
GitHub/GitLab/BitBu= cket/etc. briefly.

A contributor wants su= bmit a change.

Note how you ag= ain start from a change, not from a report of some
issue/bug= .  As Emacs is a very old and stable project, most of our
changes fix bugs, not add new features.  Therefore, use cases that
begin with issues are much more important to the workflow and= to
assessing the utility of the tools.

Any contributor can freely submit a pull reques= t that has the word `Fixes #(Issue number)` and when the pull request is acc= epted, the issue is automatically closed.

because IMO many of the issues were described in exaggerated fo= rm

Exaggerated in which sens= e?

In the sense of representin= g various aspects of the current flow as
abysmally inadequat= e, and the proposed solutions as no less than a
panacea.

Both workflows are inadequate,= and overly complicated, but most people will be more familiar to the Gitlab= Pull request workflow, and greatly lowers the bar for people who would like= to contribute for the first time.

= I don't like that, mainly because text editing facilities of a browser=
are vastly inferior to what I'm used to expect from Emacs= .

I understand. That's why I= want to figure out whether we can add changes
to GitLab, so (almost) everything also can be done= outside the
webbrows= er, and from emacs. Or maybe build something like the debbugs
package for emacs.

Personally, I think an Emacs client is almost a= must, if we want to
consider something like GitLab seriousl= y.

There are many Emacs clients that t= ightly integrates with magit; I assume you use magit for managing git repos?=  

The best one IMO is the official (magit) one= :
Manula: https://magit.vc/manual/forge/

I=E2=80=99m not sure if commen= ting on PRs are available; (I don=E2=80=99t use that feature particularly) b= ut I regularly create issues/PRs and push them, fetch them, etc... and notif= ication is also available :-)

It works with Github a= nd Gitlab, and semi-supports Gitea and other forges.

(The initial setup needs the web UI when using Gitlab though; as the Gitla= b API doesn=E2=80=99t support create a token unless Github.)

Discussing a bug report or a patch in a browser is thus i= nefficient
and quite frustrating, especially when advanced= text editing and
processing is needed.  A browser al= so takes me a step further from the
source code (you don't= suggest that I use File->Open of the browser to
<= /blockquote>
browse= the code, right?).

Well, me= ntion you mention a commit hash in your comments, the hash
becomes clickable

I didn't mean the commit itself, I meant Emacs sou= rces in general.  I
frequently need to look up source f= ragments and definitions of various
macros and structs when I= review a patch.  Since the browser have no
idea where t= he sources are, and is not in general a good tool for
viewin= g sources of a software project, it is much less helpful here.

With emacs(see magit/forge), this is not= an issue anymore! :-)

<= blockquote type=3D"cite">Probably the most complicated about the curre= nt bug tracker, at least
from irregular contributor's POV, is interacting to a existing bug:
Where do I send the email= to? Who do I CC? How do I set In-Reply-To?

In any decent MUA (certainly with Emacs MUAs), this is almost t= rivial:
the defaults always DTRT.  You don't need to th= ink about any of that.

= On debbugs, I also always forget how to use the control server<= br>
commands.

Having a need to use the control command is rare= , so I don't think
this is a serious disadvantage.  Bes= ides, tricky control commands will
give you that with any to= ol.

GitLab fixes t= hat by showing buttons for actions like
close/reopen/label/assign...

There are maybe 2 or 3 people in the Emacs project who use= these
actions, so I'm not sure why we should be so interest= ed in them.

Yes, I= tried to stress the importance of email too. I regret to hear the
email interface of GitLab didn= 't work for you. I'll have a look whether
I can suggest changes to make the "litter" configurable= . But besides
from th= at, are there any other annoyances you've encountered so far?

I don't know.  If the email notificatio= ns can be configured to work
reasonably well, and could be r= esponded to by email, that might be
enough to start a more s= erious evaluation of the workflow.

As magit/forge supports viewing notifications about the repo in the m= agit interface; this is no longer an issue anymore.

And one more thing: Emacs is I think special in how we work as a
team.  Most of the people who respond to bug report an= d review patches
have write access to the repository, and m= any of them are trusted to
push changes without approval. &= nbsp;It sounds like Gitlab has a very
different team organ= ization in mind, but maybe I'm mistaken.

GitLab shouldn't try to force you in some organisation structur= e

We'll need to explore this m= ore, I think.  It was my impression that
many defaults t= here were configured for a certain hierarchical
organization= of the team, which is not what we have here.

= --Apple-Mail-22B7F91D-9A9C-4335-A3F4-9DB1EAD1563D--