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 16:38:30 +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> <83ef55eapl.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="162257"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, acm@muc.de, toon@iotcl.com, agrambot@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 09:39:31 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 1hPMbS-000g6B-7R for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 09:39:30 +0200 Original-Received: from localhost ([127.0.0.1]:55535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPMbR-0007la-0A for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 03:39:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPMal-0007lI-PA for emacs-devel@gnu.org; Sat, 11 May 2019 03:38:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPMah-0001Yy-JW for emacs-devel@gnu.org; Sat, 11 May 2019 03:38:47 -0400 Original-Received: from pv50p00im-ztdg10021201.me.com ([17.58.6.45]:57392) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPMae-0001Ue-9S for emacs-devel@gnu.org; Sat, 11 May 2019 03:38:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557560315; bh=TK/IXindMgZPcKJ4lf7RpihBivwuqmcV6Pqeg7ONBmU=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=FQ38DFxpqIpmOsPgUZfM1IEzMqTRXrLvP4OD2ml1QZ6jPX7eH15QptzmPZ0PQ+JNy id01c6HisAEJwskNsOKbwwzT7bJkvW22aqqu2ugtB2IVJ3bROLGZnYCovEAOUdwv6r UZ8IAYWMGLTxs0bTUaHbxgpDshVlXdZokydH9T2oZ/VDf5PUS6DddjZlsfMFuSbFpG kUZFNikB2GtfOkrGSenr27TWHigjBn0hUQGl80WZ2wW6OzVbnhsaV/dvreahK0DzlT tzTKQBmQYASnu4pSGFyIx56xHMF7wgRwsjVhDU4JtxOpvcKjA5sKffufjvrISuDV8K i0wIgjRSfK4WA== Original-Received: from [10.129.64.174] (unknown [223.38.30.158]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id E7E31A40322; Sat, 11 May 2019 07:38:34 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <83ef55eapl.fsf@gnu.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 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-1905110053 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:236410 Archived-At: 2019. 5. 11. =EC=98=A4=ED=9B=84 4:01, Eli Zaretskii =EC=9E=91= =EC=84=B1: >> From: =EC=A1=B0=EC=84=B1=EB=B9=88 >> Date: Sat, 11 May 2019 12:47:27 +0900 >> Cc: Alex Gramiak , Eli Zaretskii , >> emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca, >> dgutov@yandex.ru >>=20 >> So the outsider can =E2=80=98fork=E2=80=99 the repo, to make an exact clo= ne of it, push his/her changes(commits) to GitLab, >> and make a merge request. The pull/merge request is a request the core co= ntributor 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). >=20 > Does "clicking a button" take care of various minor details I > frequently need to do when applying patches from random contributors, > such as fixing the log messages (or providing them in the first > place), adding a reference to the bug/issue, adding the > Copyright-paperwork-exempt tag, etc.? I=E2=80=99m not sure about what =E2=80=98log messages=E2=80=99 mean. If you=E2=80=99re saying commit messages, you can view them and ask the cont= ributors to fix the messages, rebase the commits, and force-push them. You c= an merge them afterwards. And yes, GitLab adds the reference to the issue, which commit or PR resolves= this issue. About adding the copyright/paperworks, there isn=E2=80=99t a default setting= , but you can have a bot to do that. I=E2=80=99ve never used one myself, so I= =E2=80=99m not sure, but I=E2=80=99ve seen lots of projects that use bots to= get paperwork, etc...=20 >> When the core contributor decides that the PR is done and merges it to th= e main repo, GitLab automatically >> closes the issue. (If the PR was found to be an incomplete solution, the i= ssue can be re-opened.) >=20 > We currently have the opposite situation: pushing a fix doesn't > automatically close the issue. Both are bad as defaults, because IME > what needs to be done is split roughly 50%. So a much better UI would > be to force the user to check a box when "clicking the merge button". Mentioning (and closing) issues in commit messages/PR messages are completel= y optional; If you feel that this commit or PR fix shouldn=E2=80=99t close t= he issue, you just don=E2=80=99t have to mention the issue, and ask the issu= e reporter check if the commit/PR fixes the particular issue, etc... >> If you=E2=80=99re saying what=E2=80=99s the point of having two types of t= opics(issues and PRs), it=E2=80=99s that PRs are primarily a >> way to put code, while issues are primarily a way to report bugs, feature= requests. >=20 > There's no such distinction in practice, it is a purely artificial > thing. There should be only one category, whether there is or isn't a > PR. But I don't think this aspect should be of any significant > importance, it's just a fluke to get used to. Think as a PR a commit that needs authorization; We don=E2=80=99t mix commit= s with issues :-)=