From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Wed, 20 Mar 2019 00:59:41 +0300 Message-ID: <1553032781.15837.0@yandex.ru> 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> <837ecvux2q.fsf@gnu.org> <9c7cf558-a2d3-951e-d6e1-31b3ad5900cf@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="254146"; mail-complaints-to="usenet@blaine.gmane.org" Cc: theophilusx@gmail.com, emacs-devel@gnu.org, Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 19 23:00:42 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 1h6Mmo-00141r-14 for ged-emacs-devel@m.gmane.org; Tue, 19 Mar 2019 23:00:42 +0100 Original-Received: from localhost ([127.0.0.1]:38112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6Mmn-0001Mw-1K for ged-emacs-devel@m.gmane.org; Tue, 19 Mar 2019 18:00:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6Mmc-0001Mg-SH for emacs-devel@gnu.org; Tue, 19 Mar 2019 18:00:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6Mmb-0006RJ-C1 for emacs-devel@gnu.org; Tue, 19 Mar 2019 18:00:30 -0400 Original-Received: from forward103p.mail.yandex.net ([77.88.28.106]:39338) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h6Mlw-0005ei-R7; Tue, 19 Mar 2019 18:00:07 -0400 Original-Received: from mxback3j.mail.yandex.net (mxback3j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10c]) by forward103p.mail.yandex.net (Yandex) with ESMTP id 6616718C0E97; Wed, 20 Mar 2019 00:59:43 +0300 (MSK) Original-Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback3j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id xVL3KI72cg-xhcWvYLe; Wed, 20 Mar 2019 00:59:43 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1553032783; bh=oygNmKheOYKSFmOJr+I6//6865/ZbXz6KgXb2E2PCwA=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=gp8kS0A+jLmOFaQfZd8wBTfkFBziYT494JqySqyZCgEd9n9zM3DZLh+/67m2kfUML Gny7cxNfsYwIc4b2cVjbO7RaUFd8nkU5Qo28SJFE7aMWjK2ntOrSve3/JSDWW8RR+Z PwpkcsIx68B4ghYXAZkcuB9MUImL09v6LEDryiTA= Authentication-Results: mxback3j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id j4kSGCA0y3-xgnK0eA9; Wed, 20 Mar 2019 00:59:42 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-Reply-To: <83sgviu3vy.fsf@gnu.org> X-Mailer: geary/master~g91967edc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 77.88.28.106 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:234381 Archived-At: =F7 =F7=D4, =CD=C1=D2 19, 2019 at 9:15 =F0=F0 (PM), Eli Zaretskii=20 =CE=C1=D0=C9=D3=C1=CC: >> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org >> From: Dmitry Gutov >> Date: Tue, 19 Mar 2019 16:13:53 +0200 >>=20 >> the Savannah UI is mostly unused by everybody. >=20 > Savannah UI and Savannah are not identical, far from that. >=20 >> Of course not. Not every potential contributor anyway. Further, if=20 >> I'm >> reviewing a random patch, *I* don't know if the contribution=20 >> satisfies >> the CA requirements. If an automatic checking process were=20 >> available, I >> could just respond with "Thanks!" and merge. >=20 > Such automated checking is n ot easy to set up, because the copyright > assignment database includes some details that are private and cannot > be exposed to public interfaces. So someone will have to come up with > a service that publishes only the public parts of that, and even then > there will be some rare cases where a manual check will be needed. >=20 >> >> At least some of these checks could be automated on a CI. >> > >> > They can also be automated by Git commit hooks. It's just a=20 >> matter of >> > someone doing the job. >>=20 >> Hooks can help, but if Emacs doesn't even allow one to *commit* a >> change, it might discourage that person from continuing, or >> investigating the failed requirement. We can add too many checks to >> commit hooks. >=20 > It is all too easy to disable/bypass the hooks, as you probably know > very well. So this doesn't sound like an important issue to me. It looks too easy when you already know how it works. An aribtrary=20 newcomer don't. When a newbie wants to change a code, they don't need to know all=20 contribution details, because they're in hacking stage. They're just=20 getting acknowledged with the code, they exercise their coding and=20 debugging skills. It's the most fragile stage, you don't want to put=20 any artifical obstacles here, because there's already a lot of=20 unknowns, they may just get overwhelmed. Btw, Emacs already has at least one git hook, and it's so annoying! The=20 hook simply aborts a commit when sees "signed-off-by" message. I'm=20 using autocompletion in zsh with `git commit -sv` as last command, so=20 it's something I do reflexively. And, while I do appreciate the check=20 itself, but having to rewrite a commit message another time isn't nice.=20 You might ask me "c'mon, usually there's very little text". Well, while=20 that's true most of the time, but for non-native english speaker even=20 writing one paragraph may take a bit more effort to do the=20 proof-reading, fixing wrong articles, etc. And it's annoying having to=20 rewrite that again. My point is: moving these destructive checks to the moment of the=20 actual contribution to upstream (i.e. the gitlab CI that runs for every=20 merge-request) would make more pleasant experience for contributors,=20 whilst not taking anything from maintainers (sure, "fix unit-test=20 failures that your commit caused" is something that a contributor could=20 probably figure out themselves). =