From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 19:49:31 +0200 Message-ID: <83k1gxwfv8.fsf@gnu.org> References: <1552789070.5272.1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="66528"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 18:56:34 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 1h5a1R-000HDl-Kl for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 18:56:33 +0100 Original-Received: from localhost ([127.0.0.1]:58361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5a1Q-0007Yz-LU for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 13:56:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5a1F-0007Ql-VQ for emacs-devel@gnu.org; Sun, 17 Mar 2019 13:56:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5Zut-00088T-0K; Sun, 17 Mar 2019 13:49:47 -0400 Original-Received: from [176.228.60.248] (port=1977 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h5Zus-00049m-22; Sun, 17 Mar 2019 13:49:46 -0400 In-reply-to: <1552789070.5272.1@yandex.ru> (message from Konstantin Kharlamov on Sun, 17 Mar 2019 05:17:50 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:234283 Archived-At: > Date: Sun, 17 Mar 2019 05:17:50 +0300 > From: Konstantin Kharlamov > Cc: emacs-devel > > It's a lot of contributors out there; at the same time, I see very > little patches on emacs-devel list. Patches should not be sent to emacs-devel at all, they should be sent to the debbugs tracker. And I looked at the bug list for the past 2 weeks, and counted around 25 patches there, i.e. an average of 1.5 patch per day -- not a small amount by any measure. > A lot of open-source projects already migrated to gitlab: all > FreeDesktop projects, all Gnome projects; and KDE are likely to migrate > soon too². I can show you several projects that didn't. Each project decides on their own, as it should be. > Gnome reports: "After switching to GitLab, I noticed almost > immediately an increase in contributions from people I hadn’t met > before. I think GitLab really lowered the threshold for people > getting started"³. I don't know enough about these projects to tell whether their experience is significant enough for us. Some metrics are missing: how many SLOCs are in each project? how many distinct areas of domain expertise are needed to cover the entire codebase? how many developers who review patches? which language(s) is each project written in? etc. etc. In general, Emacs is unlike any other Free Software project by many of these metrics, so techniques and procedures that work elsewhere don't necessarily fit what happens here. We must assess the techniques, procedures, and the respective tools in the context of the problems we need to solve and the resources we have to solve them. Blindly copying experience by others is not a good idea. > here's a rarely mentioned point, why in particular mailing-list > workflow is hard for newcomers: almost every mail client out there > breaks formatting by default; and configuring that out isn't always > easy This is Emacs you are talking about, and Emacs developers you are addressing. Most of us use some Emacs-based MUA, where such atrocities just don't happen. > 2. Gitlab makes addressing review comments easier. With mailing lists > workflow you either need to α) send a v2 of the patch; which is a > little frustrating: you need to find message-id to feed it to > git-send-email, and then you need to make sure its title lines up with > the rest of the series. Or β) resend whole patch-series; which can be > just redundant when all you did was a one-line change, and clutters the > mailing list. Also, upon sending v3, v4, etc. you need to save > somewhere changes since v1. You can put it in actual commits, but for > git-history this information is unnecessary. You seem to be talking about something that happens in other projects. There are no requirements in Emacs development to do any of that stuff: you don't need to give versions to your patches, you don't need to make sure the titles match, etc. We don't even require you to use "git format-patch", although it is certainly appreciated. You _can_ do all of that if you want, but no one requires you to. Quite a few people sent just output of the 'diff' command, and no one rejected that just because it didn't include all the bells and whistles. So I see no reason for contributors to do anything beyond starting a local branch and delivering the patches from there. I'm sure sending patches relative to the master branch is very simple, even with Git. And if even that is too complicated, simply rebase on the latest master and send the diffs. How hard can that be? > With gitlab workflow, on the other hand, you just force-push changes > to the branch that has merge-request opened. A single command, that > it. Likewise to send a patch from a local-branch commit: a single command, issued from your Emacs MUA via "C-u M-!". > 3. CI. I've recently seen someone on emacs-devel⁵ asking a > contributor to run their syntax-checking script on a regular basis. > That's becase you can't run any check on a code hanging out there on a > mailing list in pure air. Gitlab supports CI, i.e. one can set it up to > run unit-tests for every merge-request created, so these errors get > caught before getting to the tree; and possibly even before getting to > eyes of reveiwers. We already have a server that runs several types of build on each commit, courtesy of Glenn. If you stick around long enough, you will see Glenn blaming commits that broke some build. This is not exactly CI, and it runs only on something that lands on master, but it does mean we are not exactly in the caves here, even without Gitlab... > 4. Impossible to lose "merge request". I've seen in Emacs docs an > advice to send patch series to a bugtracker, because on emacs-devel > they can easily be forgotten. That can't happen so easily with gitlab, > where you have a tab with open merge requests. Can't happen on the tracker, either. Yes, patches should be sent there, not here. > 5. Discussion on patch series is easier to read. On mailing lists can > quickly appear a dozen of no longer relevant review mails, that refer > to something that was addressed. In Gitlab the addressed comments can > be marked as such, and get collapsed. I can assure you I am able to filter my email messages as efficiently as collapsing on Gitlab, if not more so. I really hope a new system that we will some day start using will give us more than just an ability to filter out irrelevant responses. > 6. More tightly integrated bugtracker. When a commit refers to an > issue, it can be seen from inside the issue. This is useful e.g. when > someone fixed a problem, but for some reason couldn't address review > comments, leaving the code behind. Then later peoples who stumble upon > the same issue can just improve the code instead of doing research and > writing it on their own. You can view each bug/issue via an Emacs package (debbugs, it's on ELPA), or via a Web browser. In this way, you also see all the patches, and can pick up where others left off. > 7. Unclear how to download a patch-series from mailing list. Again, try the debbugs package or point your Web browser to debbugs. Patches are all there. That said, I'm not saying we should not consider changing our processes and tools. We just need to do that while being aware of the job(s) to be done by patch reviewers and the resources they have. For starters, how many people do you think review patches for Emacs? It's good to know the answer before we discuss measures for increasing the patch flow... Thanks.