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: Thu, 25 Apr 2019 11:32:59 +0300 Message-ID: <83zhoezdqc.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="137772"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru To: Toon Claes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 25 10:34:41 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 1hJZq4-000Zhd-Th for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 10:34:41 +0200 Original-Received: from localhost ([127.0.0.1]:53849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJZq3-0008Fr-RZ for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 04:34:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJZoo-0008E7-5F for emacs-devel@gnu.org; Thu, 25 Apr 2019 04:33:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJZon-0005HA-4F; Thu, 25 Apr 2019 04:33:21 -0400 Original-Received: from [176.228.60.248] (port=2023 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hJZom-0004GG-A6; Thu, 25 Apr 2019 04:33:20 -0400 In-reply-to: <87pnpc1lby.fsf@iotcl.com> (message from Toon Claes on Tue, 23 Apr 2019 23:08:17 +0200) 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:235908 Archived-At: > From: Toon Claes > Gcc-Self: nnimap+soverin:Sent > Date: Tue, 23 Apr 2019 23:08:17 +0200 > Cc: Stefan Monnier , Alex , > emacs-devel@gnu.org > > > I fear it's a bit premature, considering we've not worked out the > > minimum requirements between ourselves yet, and Eli has not approved > > even minimal steps toward moving to GitLab. > > I know Eli didn't approve. I didn't "didn't approve" "even the minimal steps", that's a gross misunderstanding of what I wrote. It is a bit hard to summarize all I said in a few sentences, but if I have to, it's that I don't yet see a clear overall picture of the workflow (or workflows, if there will be a few) enough to make up my mind about the proposed changes. I don't even understand what concrete changes are being proposed. Beyond my relative lack of familiarity with Gitlab, it provides a large number of features, and it is not yet clear to me which ones are included in the proposal. It might make sense to produce a list of typical tasks and their proposed alternatives using Gitlab. In the referenced discussion, I tried (and I guess failed, given the above "summary") to word my messages not as rejection, but as a critical assessment of the issues raised by others, because IMO many of the issues were described in exaggerated form, and the proposed solutions were described in an optimistic, even simplistic, way that disregarded important factors and issues in Emacs development and maintenance that I and others have to deal with every day. IOW, my intent was to try to balance the picture, not to reject the proposals. > https://gitlab.com/gitlab-org/gitlab-ce/issues/60684 Thanks. I think it's a good idea to maintain a list of issues that we need to address, and this is a good start. (A naïve question: there's no "emacs" in the URL, so how does this issue relate to the project? And what do "org" and "ce" signify in this context?) Allow me now to provide some comments on this. They are my personal views at this point, not the project's position. (They might become the project position if enough active developers agree with what I say.) And please forgive any inaccurate/naïve/silly things I write due to lack of familiarity with Gitlab. I intentionally limit myself to only the few major issues, for now; I think the details should be addressed only after the main issues are resolved and/or decided. My main problem with Gitlab is that AFAIU it requires to do most of the work from a Web browser outside Emacs (I believe EWW is not up to this job, right?). I don't like that, mainly because text editing facilities of a browser are vastly inferior to what I'm used to expect from Emacs. Discussing a bug report or a patch in a browser is thus inefficient and quite frustrating, especially when advanced text editing and processing is needed. A browser also takes me a step further from the source code (you don't suggest that I use File->Open of the browser to browse the code, right?). So I think having efficient integration with Emacs is very important for making the migration attractive, at least to me. The second major issue is with bug reports. This is mentioned towards the end of the issue, but it is IME much more important than merge requests, because currently most of the traffic on the bug tracker is bug reports, not patches. Efficient handling of the reported issues is therefore much more important for me than handling of patches, and I didn't get the impression there's a lot Gitlab can offer in that direction. I'd be happy to be mistaken, but if not, IMO we must provide efficient tools for dealing with bugs, including pinging assignees after predefined period of time, reassignment requests after a predefined number of pings, efficient search of bug database for related issues, a good tagging system for quickly finding related issues, etc. Next, it is not clear to me how will this affect my Git workflows. Before I push a changeset, I like to build Emacs on my system, perhaps run Emacs under a debugger and look around at relevant variables, run some tests that I think are relevant, etc. It sounds like with Gitlab all that must be done remotely, on some other machine? And if I want it on my machine, I will need to checkout a non-master branch and build it? That would be inconvenient, to say the least. One of the main advantages of a dVCS is that you can do so many things locally, even when your network connection is down. Last, but not least: the email interface. First, please don't under-estimate its importance. For people who are involved in several projects beside Emacs, and cannot afford sitting all day long staring at the Gitlab UI in the browser, email is important because it doesn't require polling, it brings the stuff pretty much into one's face. But it must be done efficiently. And here my admittedly limited experience with Gitlab is abysmally bad: the one project that migrated to Gitlab basically flooded my inbox with unimportant notifications like assigning and reassigning issues, changing the issue's severity, and other similar litter. I tried to configure the notifications, but failed to do so (perhaps due to insufficient permissions?), and the only thing that worked was to disable them altogether. I think the email interface must be very good, flexible, and powerful, if we want to encourage migration. And one more thing: Emacs is I think special in how we work as a team. Most of the people who respond to bug report and review patches have write access to the repository, and many of them are trusted to push changes without approval. It sounds like Gitlab has a very different team organization in mind, but maybe I'm mistaken. I think this is enough for now. Thanks for listening.