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: Sat, 11 May 2019 12:47:27 +0900 Message-ID: References: <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> <17D21056-10B2-4813-AE90-9B2706936CE9@icloud.com> <83imuifqjc.fsf@gnu.org> <87lfzehrug.fsf@gmail.com> <20190511021206.GA4049@ACM> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-882E4596-A2CD-458C-92EE-860BBC290DC6 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31472"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, Eli Zaretskii , toon@iotcl.com, Alex Gramiak To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 05:56:40 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 1hPJ7n-000834-6C for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 05:56:39 +0200 Original-Received: from localhost ([127.0.0.1]:53374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPJ7m-0003fs-7s for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 23:56:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPJ7e-0003FU-6v for emacs-devel@gnu.org; Fri, 10 May 2019 23:56:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPIz1-0002U3-13 for emacs-devel@gnu.org; Fri, 10 May 2019 23:47:36 -0400 Original-Received: from pv50p00im-ztdg10012101.me.com ([17.58.6.49]:44990) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPIz0-0002T6-0G for emacs-devel@gnu.org; Fri, 10 May 2019 23:47:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557546451; bh=GMYxxZNLVXWNd8gWfL+0hQtmJElgkGYVbQxOcqw7d5o=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=PFG+rwMdrnpKurL2q5K0GuLp8sDtVhqXMvTHcSUzxfGQE32n5GGYOviH0RGAVHFDD zRfrfycZwsE15VaGQ1kH2wLe0BSxEXexZPUhVeuAE0vHr83L07JtSVcXvRJhU20244 bUtwsdoa3AZHu3FTBgBqPY63Tq/AVQX9SmjTez/3ZK8El6Yht0Et/aj6j1xMf5gop9 U4JLl1LQ0wzy43UPhHK+jYKvIyNpr+Gvouu0pnMxNOJwslkbiDW/bPO/mtDO9362rU HpeOu/zGzL6O/UlBXq5qNv7cC6HQI5HWtYSa2m/6OCG9idyE4sLoq5n7/LKytp53oO 6cUjLzTnnOMAQ== Original-Received: from [192.168.0.8] (unknown [1.230.108.64]) by pv50p00im-ztdg10012101.me.com (Postfix) with ESMTPSA id CB6ED84063E; Sat, 11 May 2019 03:47:30 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190511021206.GA4049@ACM> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-11_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-1905110024 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.49 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:236401 Archived-At: --Apple-Mail-882E4596-A2CD-458C-92EE-860BBC290DC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 2019. 5. 11. =EC=98=A4=EC=A0=84 11:12, Alan Mackenzie =EC=9E=91= =EC=84=B1: > Hello, Alex. >=20 >> On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote: >> Eli Zaretskii writes: >=20 >>> My point was that an absolute majority of Emacs issues don't have a >>> patch attached. They describe a problem, and most of the reports >>> don't even include a detailed analysis of the problem and its root >>> cause. A large part of discussing an issue is devoted to >>> understanding the issue and then finding its cause. Patches appear >>> only after all that. >=20 >>> So we must have a good support for a workflow that doesn't include any >>> pull/merge request at its beginning, maybe even never. >=20 > I don't know what "pull/merge request" means. Does it mean a request by > an outsider for a core contributor to perform a "git pull" operation > from the outsider's computer, the outsider having opened up his machine > to public access to allow this? An outsider that is not a core contributor cannot make a new branch (as he/s= he doesn=E2=80=99t have enough authorization). So the outsider can =E2=80=98fork=E2=80=99 the repo, to make an exact clone o= f it, push his/her changes(commits) to GitLab, and make a merge request. The= pull/merge request is a request the core contributor to =E2=80=98pull=E2=80= =99 the changes of the forked repo and =E2=80=98merge=E2=80=99 it just as if= the forked repo is just another branch. This can be done by just clicking a button to merge(in the web UI). Merging is also available in the command line; see https://gist.github.com/a= dam-p/15413fabef6cffecd897 ; but I=E2=80=99ve never seen anyone merging PRs l= ike that in real life. >> Gitlab et al. would provide that, IMO. When there's no PR/MR at the >> beginning, the topic is submitted as an "Issue" and given a unique issue >> number. However, patches aren't submitted to the issue: rather, a new >> PR/MR is created, given a unique MR number, and is linked with the >> relevant issue(s). >=20 > Yuck! I recently worked with a proprietory system where each bug had > several different numbers, an issue number, an analysis number, a patch > number, and so on. It caused extra effort to keep track of bugs, and > was generally horrible. IIRC Gitlab uses one number for all =E2=80=98topic=E2=80=99s, but there are t= wo types of topics(e.g. issue and PR). If you were annoyed that there are fe= w types of different numbers, (e.g. Bug#71 and Analysis#71), GitLab is not t= he case. There is only one #71 and it=E2=80=99s an issue or PR. >> When the PR/MR is merged, any linked issues are closed. >=20 > You needn't have used the passive voice, there. What does your sentence > mean? That when a user merges a PR/MR, gitlab automatically closes the > issue (whether it's finished, or not)? Or that a user can close an > issue only after somebody has first merged at least one PR/MR? Or > something else? When the core contributor decides that the PR is done and merges it to the m= ain repo, GitLab automatically closes the issue. (If the PR was found to be a= n incomplete solution, the issue can be re-opened.) > What is the point of issues and PR/MRs having distinct identifiers, if > they are so tightly coupled with eachother? As I mentioned before, they don=E2=80=99t have =E2=80=98distinct=E2=80=99 id= entifiers; any issue/PR can cross-reference other issue/PR with the number. If you=E2=80=99re saying what=E2=80=99s the point of having two types of top= ics(issues and PRs), it=E2=80=99s that PRs are primarily a way to put code, w= hile issues are primarily a way to report bugs, feature requests. If an core contributor fixed an issue, one doesn=E2=80=99t have to create a P= R(as he/she already has commit; he/she can just mention the issue number in t= he commit message and it will be automatically closed. >> This means that the discussion gets separated into two parts: the >> discussion about the issue/problem (kept in the "Issues" category), and >> the discussion about the patch/solution (kept in the "Merge Requests" >> category). >=20 > This sounds like a Bad Thing to me. It sounds rather like a workflow > being imposed which imagines that first the bug gets "resolved" > (whatever that means) in discussion, and only then does work start on a > separate "merge request". The above mentioned proprietory system was > like this. It didn't lend itself to a natural and efficient way of > working. No, one can interact with the bug while writing a patch and making a PR (or a= commit). You can make a PR and continue to modify the PR (as the bug gets r= esolved?) until it becomes merged. > --=20 > Alan Mackenzie (Nuremberg, Germany). >=20 --Apple-Mail-882E4596-A2CD-458C-92EE-860BBC290DC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
2019. 5. 11. =EC=98=A4= =EC=A0=84 11:12, Alan Mackenzie <acm@muc.de= > =EC=9E=91=EC=84=B1:

Hello, Alex.

On Fri, May 10,= 2019 at 16:23:03 -0600, Alex Gramiak wrote:
Eli Zaretskii <eliz@gnu.org> writes:

My point was that an absolute majority o= f Emacs issues don't have a
patch attached.  They desc= ribe a problem, and most of the reports
=
don't even include= a detailed analysis of the problem and its root
cause. &n= bsp;A large part of discussing an issue is devoted to
unde= rstanding the issue and then finding its cause.  Patches appear<= br>
only after all that.

So we mus= t have a good support for a workflow that doesn't include any
pull/merge request at its beginning, maybe even never.

I don't know what "pull/merge requ= est" means.  Does it mean a request by
an outsider for a= core contributor to perform a "git pull" operation
from the= outsider's computer, the outsider having opened up his machine
to public access to allow this?

An outsider that is not a core contributor cannot make a new branch= (as he/she doesn=E2=80=99t have enough authorization).
So the out= sider can =E2=80=98fork=E2=80=99 the repo, to make an exact clone of it, pus= h his/her changes(commits) to GitLab, and make a merge request. The pull/mer= ge request is a request the core contributor to =E2=80=98pull=E2=80=99 the c= hanges of the forked repo and =E2=80=98merge=E2=80=99 it just as if the fork= ed repo is just another branch.
This can be done by just clicking a= button to merge(in the web UI).
Merging is also available in the c= ommand line; see https://gist.github.com/adam-p/15413fabef6cffecd897 ; but= I=E2=80=99ve never seen anyone merging PRs like that in real life.
= Gitlab et al. would provide that, IMO. When there's no PR/MR at the
beginning, the topic is submi= tted as an "Issue" and given a unique issue
number. However, patches aren't submitted to the issu= e: rather, a new
PR/M= R is created, given a unique MR number, and is linked with the
relevant issue(s).

Yuck!  I recently worked with a propriet= ory system where each bug had
several different numbers, an &= nbsp;issue number, an analysis number, a patch
number, and s= o on.  It caused extra effort to keep track of bugs, and
was generally horrible.

IIRC Gitlab u= ses one number for all =E2=80=98topic=E2=80=99s, but there are two types of t= opics(e.g. issue and PR). If you were annoyed that there are few types of di= fferent numbers, (e.g. Bug#71 and Analysis#71), GitLab is not the case.
There is only one #71 and it=E2=80=99s an issue or PR.

When th= e PR/MR is merged, any linked issues are closed.

You needn't have used the passive voice, there.  Wha= t does your sentence
mean?  That when a user merges a P= R/MR, gitlab automatically closes the
issue (whether it's fi= nished, or not)?  Or that a user can close an
issue onl= y after somebody has first merged at least one PR/MR?  Or
something else?

When the core contr= ibutor decides that the PR is done and merges it to the main repo, GitLab au= tomatically closes the issue. (If the PR was found to be an incomplete solut= ion, the issue can be re-opened.)

What is the point of issues and PR/MRs having distinct ident= ifiers, if
they are so tightly coupled with eachother?

As I mentioned before, they don=E2= =80=99t have =E2=80=98distinct=E2=80=99 identifiers; any issue/PR can cross-= reference other issue/PR with the number.

If you=E2= =80=99re saying what=E2=80=99s the point of having two types of topics(issue= s and PRs), it=E2=80=99s that PRs are primarily a way to put code, while iss= ues are primarily a way to report bugs, feature requests.

If an core contributor fixed an issue, one doesn=E2=80=99t have to cr= eate a PR(as he/she already has commit; he/she can just mention the issue nu= mber in the commit message and it will be automatically closed.

This= means that the discussion gets separated into two parts: the
discussion about the issue/problem (= kept in the "Issues" category), and
the discussion about the patch/solution (kept in the "Merge Req= uests"
category).

This sounds like a Bad Thing to m= e.  It sounds rather like a workflow
being imposed whic= h imagines that first the bug gets "resolved"
(whatever that= means) in discussion, and only then does work start on a
se= parate "merge request".  The above mentioned proprietory system was
like this.  It didn't lend itself to a natural and efficie= nt way of
working.

No, one can interact with the bug while writing a patch and making a PR (= or a commit). You can make a PR and continue to modify the PR (as the bug ge= ts resolved?) until it becomes merged.

--
Alan Mackenzie (Nuremberg, Germany).<= /span>

= --Apple-Mail-882E4596-A2CD-458C-92EE-860BBC290DC6--