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 22:09:28 +0900 Message-ID: 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> <17D21056-10B2-4813-AE90-9B2706936CE9@icloud.com> <83imuifqjc.fsf@gnu.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="18215"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, 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 15:09:56 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 1hP5Hf-0004ZQ-CV for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 15:09:55 +0200 Original-Received: from localhost ([127.0.0.1]:43041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP5He-0001eY-9t for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 09:09:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP5HU-0001dF-I3 for emacs-devel@gnu.org; Fri, 10 May 2019 09:09:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP5HT-0001aQ-3E for emacs-devel@gnu.org; Fri, 10 May 2019 09:09:44 -0400 Original-Received: from pv50p00im-ztdg10021201.me.com ([17.58.6.45]:40952) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hP5HS-0001Xs-Qe for emacs-devel@gnu.org; Fri, 10 May 2019 09:09:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557493772; bh=lrTkiYmZCMd1jbOVpBK9kb0S7S7bRacOyCCfGtcIL48=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=nYFv7dEm6H8jE3eQn2BLJH0YnctrJrD2oiv8AQVUQmS96Dw8w0y6fEkyQbICuTLds vlpkcp9HZRCU+XiEp03apjCF4dxXfOEbev1ZYs+pwokq7a7LJMTVlIwN6VP6fSkoKh KFsaqrr5CTr6IcZQVRZF6JLqaGdrIJSlciBAQnmH0+D4icNlcHk1HmWSRS2JJTg52a lzaMVbwNTxfFPbQm43teaAmyYuA10xBnboQeQQd5YN0vjP4WREuWVjub6y1JeAdr3J T7yfeqjkGPcKZ3sbTKIPuLTtDxUy/WnGwKC2SG8pYDaEzZsv/ovSatXn3yk6EBDJBS /tnv+d2R45GDg== Original-Received: from [10.129.64.174] (unknown [223.38.30.158]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id D1AA6A40A5D; Fri, 10 May 2019 13:09:31 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <83imuifqjc.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=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905100093 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.45 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:236366 Archived-At: 2019. 5. 10. =EC=98=A4=ED=9B=84 9:21, Eli Zaretskii =EC=9E=91= =EC=84=B1: >> From: =EC=A1=B0=EC=84=B1=EB=B9=88 >> Date: Fri, 10 May 2019 19:37:31 +0900 >> Cc: Toon Claes , dgutov@yandex.ru, monnier@iro.umontreal.= ca, >> agrambot@gmail.com, emacs-devel@gnu.org >>=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. >>=20 >> 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 automa= tically closed. >=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. Ah, I didn=E2=80=99t explain it enough. Sorry for that :-( There is an issue tracker. Anyone can submit issues(bugs) to there. There is also a Pull Request tracker. If one (not necessarily the issue opener; usually will be different) has eno= ugh authority to commit to the git repo, he/she can just commit to the main r= epo with a commit message containing (one or multiple) `Fixes #(issue number= )` and the issue is automatically closed, with an additional message `Commit= (hash number) closed this issue.` If an external (potential) contributor makes a fix for any issue (no need to= be the contributor=E2=80=99s issue) in the issue tracker, but doesn=E2=80=99= t have enough authority to commit to the main repo,=20 1) he can fork the repo 2) push/commit his changes 3) and make a pull request to the main repo 4) with the pull request message (think as another git commit message) conta= ining (one or multiple) `Fixes #(issue number)` (Optional, there is no need f= or the pull request to be associated with an issue) and one that has enough authority can review the pull request (patch) and me= rge the forked repo, just like merging a branch to another one. When the pull request is merged, the associated issue is automatically close= d. This is the basic workflow when using GitLab, and everything mentioned in th= e workflow can be done with the package =E2=80=98magit/forge=E2=80=99 I ment= ioned below. >>>> 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. >>=20 >> Both workflows are inadequate >=20 > Not really relevant to the question and the answer. >=20 >> and overly complicated, but most people will be more familiar to the Gitl= ab Pull request workflow, and greatly lowers the bar for people who would li= ke to contribute for the first time. >=20 > Please don't forget that any change should also not unduly _raise_ the > bar for the current core team, to be acceptable. I=E2=80=99m pretty sure the current workflow using emails can be applied to G= itLab; as isn=E2=80=99t it just using standard git features? >>> Personally, I think an Emacs client is almost a must, if we want to >>> consider something like GitLab seriously. >>=20 >> There are many Emacs clients that tightly integrates with magit; I assume= you use magit for managing git repos?=20 >>=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 >=20 > It sounds like you are advocating the adoption of a system other than > GitLab. If so, I think we should first decide that GitLab is not good > enough, something I believe we didn't decide yet. The magit/forge is a MELPA package that can integrate tightly with Gitlab/Gi= thub/etc... It=E2=80=99s an answer to your question about how to use the GitLab workflow= in Emacs. >> It works with Github and Gitlab, and semi-supports Gitea and other forges= . >=20 > If by "it" you mean forge, would you please describe how it would be > used in the Emacs maintenance workflows? (Having to install magit is > a certain disadvantage, but it isn't by itself enough to make this > alternative unacceptable, IMO.) Well, magit/forge is a package, which means you (and a hypothetical emacs co= ntributor) can use the GitLab workflow (explained by other people) inside Em= acs.=