From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Tue, 19 Mar 2019 08:27:10 +0100 Message-ID: References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> <1552793646.5272.3@yandex.ru> <1552821396.21432.0@yandex.ru> <83imwhwf4x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007cc6d105846d70fe" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="199501"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , theophilusx@gmail.com, Emacs developers , Konstantin Kharlamov To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 19 08:28:33 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 1h69Am-000pnk-IT for ged-emacs-devel@m.gmane.org; Tue, 19 Mar 2019 08:28:32 +0100 Original-Received: from localhost ([127.0.0.1]:52909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h69Al-0008JW-GF for ged-emacs-devel@m.gmane.org; Tue, 19 Mar 2019 03:28:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h69AA-0008JO-1r for emacs-devel@gnu.org; Tue, 19 Mar 2019 03:27:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h69A9-0002C1-4L for emacs-devel@gnu.org; Tue, 19 Mar 2019 03:27:54 -0400 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:46830) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h699w-0001q2-LE; Tue, 19 Mar 2019 03:27:41 -0400 Original-Received: by mail-lf1-x12b.google.com with SMTP id y62so5505921lfc.13; Tue, 19 Mar 2019 00:27:40 -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=UtZzxwUigTe5z2E/73VKIqPYAmVmpVq7yKHpnqE7xmM=; b=YuSWIpTMKkAy/a6fu49KpMZX8kLHomyYaoQRoJCfZzKd9RcYB2HyJeOzAMBWIrXypq cSJG+UBi0IOU0Yv0lvrp18ih2fQLCotA98sfYBSMQb1HC9j2fXhnr6IRcyQmxAbPNQxd Qat4lxnbsX175J0cAqG+kkB4yIqtpK6ouUhvQfSr9NiIXvxzn3LSoOzFqdWyCCPCZOce gpx+cGdFBMTi8QWmHfQ4DpfuHGENI+wN6XGgQC1yyFmHqGj2unPf/Bhbvb6Z8nYoutJ9 5Vk7e7xNu2xWZLzxUE7buandQ+2//6GEk2bRgDU6JpmVlu/wHm4xE6N2H9nuMQe7D/Bv EOqw== 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=UtZzxwUigTe5z2E/73VKIqPYAmVmpVq7yKHpnqE7xmM=; b=qDtsEqeC7sSQX5ed+d8VI+c8bPK7HFnRVMYn5SiKwjkUPntb5ak1PPYAHBjAs6h7pR 0jUudXhHDiP6HSZN9zRGERXRLhe8psGeOrdflIiz9QHFtwabgpbZJ2Lqo2/QlPtwReYF Kvruccv2NOaWDBWgZvnJG4DdCziQF7ngTAENdqs1xTSxCGzeFfqeKMHdtKRbHRjP+MSF FCoVwu3z88rtGXRwEhdAMcBSKLi5ZpBrnj4Jd/OYuLWjl9GP7vXZMhEMlhWxvCsXiTQp fKC5Tn7FEuVmcbOHkmcqukYzmsCp0ckBFQFTYXNpA8rIB6Atkb3NkzCqiivYt5eI7EFu NA7Q== X-Gm-Message-State: APjAAAUtvbFewrn9eXyOQEyGHoKDSCf3M4sf2tb2NBSV/MCKzaQXaG2Q BR4MkxDpE50bsZneY3eBjz+TB81yu15Ie1TUP6Q= X-Google-Smtp-Source: APXvYqyZJxjeiWuAw1EpPG0uCNfILa1i0HAyw2R6aUydFs+P98J+3gFcw93gql6z5191A35Ypou27GqWKROCV+sR8jE= X-Received: by 2002:a19:ee11:: with SMTP id g17mr3373420lfb.117.1552980457079; Tue, 19 Mar 2019 00:27:37 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::12b 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:234357 Archived-At: --0000000000007cc6d105846d70fe Content-Type: text/plain; charset="UTF-8" > > > Sending patches via email is only one requirement. There are other > > requirements peculiar to Emacs, which will not go away if we switch to > > another patch submitting system. Some of these requirements, each and > > every one of them flagged at some point as an obstacle for newcomers: > > > > . code submissions should include documentation > > . commit log messages should be formatted in a certain way > > . bug numbers should be referenced in log messages > > . US English conventions in writing comments and documentation > > (spelling, two spaces between sentences, etc.) > > . we require copyright assignments for accepting changesets larger > > than about 15 original source lines > > . we have peculiar rules regarding the branch were certain changes > > should be pushed (affects the branch against which contributors > > should prepare patches) > > . very elaborate coding and documenting conventions (their > > description takes around 900 lines in the ELisp manual) > > At least some of these checks could be automated on a CI. And the author > of a random PR would get an overview of its compliance automatically. > Also when someone creates a PR (or Issue), there can be template text (with checkboxes, etc) stating these points, so the author has a direct reminder to improve the quality of his PR or Issue before he sends it. And if he does not check all the checboxes and submit anyway, then the maintainer's job is easier because he already knows the missing parts. I believe this whole discussion is basically this: the ones who are used to a gitlab workflow see the obvious benefits, and the ones who only use the email workflow don't see what's so great about it because they always find a manual/configuration-heavy way to achieve the same. I think the manual/configuration-heavy way is not very smooth and makes _you_ work instead of the tools, when this effort could be better spent improving Emacs. Kind regards, Philippe --0000000000007cc6d105846d70fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Sending patches via email is only one requirement.= =C2=A0 There are other
> requirements peculiar to Emacs, which will not go away if we switch to=
> another patch submitting system.=C2=A0 Some of these requirements, eac= h and
> every one of them flagged at some point as an obstacle for newcomers:<= br> >
>=C2=A0 =C2=A0 . code submissions should include documentation
>=C2=A0 =C2=A0 . commit log messages should be formatted in a certain wa= y
>=C2=A0 =C2=A0 . bug numbers should be referenced in log messages
>=C2=A0 =C2=A0 . US English conventions in writing comments and document= ation
>=C2=A0 =C2=A0 =C2=A0 (spelling, two spaces between sentences, etc.)
>=C2=A0 =C2=A0 . we require copyright assignments for accepting changese= ts larger
>=C2=A0 =C2=A0 =C2=A0 than about 15 original source lines
>=C2=A0 =C2=A0 . we have peculiar rules regarding the branch were certai= n changes
>=C2=A0 =C2=A0 =C2=A0 should be pushed (affects the branch against which= contributors
>=C2=A0 =C2=A0 =C2=A0 should prepare patches)
>=C2=A0 =C2=A0 . very elaborate coding and documenting conventions (thei= r
>=C2=A0 =C2=A0 =C2=A0 description takes around 900 lines in the ELisp ma= nual)

At least some of these checks could be automated on a CI. And the author of a random PR would get an overview of its compliance automatically.

Also when someone creates a PR (or Issue), t= here can be template text (with checkboxes, etc) stating these points, so t= he author has a direct reminder to improve the quality of his PR or Issue b= efore he sends it.

And if he does not check all th= e checboxes and submit anyway, then the maintainer's job is easier beca= use he already knows the missing parts.

I believe = this whole discussion is basically this: the ones who are used to a gitlab = workflow see the obvious benefits, and the ones who only use the email work= flow don't see what's so great about it because they always find a = manual/configuration-heavy way to achieve the same.

I think the manual/configuration-heavy way is not very smooth and makes _= you_ work instead of the tools, when this effort could be better spent impr= oving Emacs.

Kind regards,
Philippe


--0000000000007cc6d105846d70fe--