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 12:22:45 +0300 Message-ID: <83sgu6zbfe.fsf@gnu.org> 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> <1553064994.13109.0@yandex.ru> <831s32t3fn.fsf@gnu.org> <93f38b88-059b-b243-49bf-df61f424fb3f@yandex.ru> <83o94zap79.fsf@gnu.org> <5161ae04-391e-49d8-e942-127c04062c27@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="96314"; mail-complaints-to="usenet@blaine.gmane.org" Cc: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 25 11:24:20 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 1hJac6-000OvT-UI for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 11:24:19 +0200 Original-Received: from localhost ([127.0.0.1]:54320 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJac5-0005hY-V2 for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 05:24:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJaay-0005dJ-0c for emacs-devel@gnu.org; Thu, 25 Apr 2019 05:23:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJaax-00052K-FW; Thu, 25 Apr 2019 05:23:07 -0400 Original-Received: from [176.228.60.248] (port=1085 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hJaaw-0007iI-Tj; Thu, 25 Apr 2019 05:23:07 -0400 In-reply-to: <5161ae04-391e-49d8-e942-127c04062c27@yandex.ru> (message from Dmitry Gutov on Thu, 25 Apr 2019 04:06:28 +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:235910 Archived-At: > Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 25 Apr 2019 04:06:28 +0300 > > On 21.04.2019 8:43, Eli Zaretskii wrote: > > > Large parts of, if not the majority, of the areas where we don't have > > active experts are not in packages that can be moved to ELPA. A lot > > of that is in C (and most cannot be recoded in Lisp, even if > > performance allowed that) or in core packages central to Emacs. > > Some features will stagnate, some we'll have to cut out in the long run. This loses context and perspective. The context was patch review, not development. If someone submits a patch that touches on one of those areas, do you propose to tell them to drop the patch because no one really understands its implications? I doubt that. The person who submits the patch might just be that future expert, and we don't want to scare them away. So we must review the patch as best as we can, and that takes an inordinate amount of time and effort. > > The patch review process should reflect the preferences of the bulk of > > those who do the review. It is IMO wrong and even unfair to force > > significant changes in the procedures due to requests from people who > > aren't involved enough, because (a) they don't have the right > > perspective, and (b) because they won't be there to sustain the > > consequences. > > Like I said, you have the authority to strongly request the transition > to be as smooth as possible, so that the important aspects of the > existing workflow are retained. It's not like you actually love every > minor detail of how we do review these days that you couldn't bear to > part even with one of them, is it? My authority, whether real or imaginary, aside, it's not just me and my habits. There are others involved, and by looking at how they format their messages and how they find related issues, I can guess that they, too, have efficient workflows in place that will have to be considered. I hope my other message could be a good starting point for figuring out what exactly will constitute a smooth transition, and what are the necessary conditions for such a transition. > > It is a bootstrap-like process, sure. My point was that we cannot > > speed it up beyond some limit, determined by balanced progress in > > these two prongs. I guess you are agreeing with that? > > Not really. I don't really understand the idea of "reaching critical > mass" in this discussion. When would you consider the "mass" to be > "critical"? When close to 80% of bugs and patches posted to the issue tracker will wait less than a week before they get responded in some meaningful way (excluding a mere acknowledge of seeing the report), and not necessarily by yours truly. Sounds good? > When somebody offers to take over as the maintainer? (I'm > hoping for a "no" here). Feel free to do that as well, it will make me a happier person. > I'm saying it's better to encourage the possible contributors to bring > their own enthusiasm and expertise, even for a while. Better than what? And anyway, the issue at hand is not a general one: we all agree that contributors should be encouraged. The issue is what to do in practice to encourage them, and the specific part of that discussed here is significant changes in the workflow. It is unclear to me what practical criteria you are proposing for this trade-off. It's not an easy decision, and just the desire to encourage is not enough. > Not every unfinished project is a loss. Someone else can come along > and continue it. Examples from Emacs? I'm not aware of any, but maybe I missed some. > In this case, I would expect a very wide range of > people to want to see Emacs migrate to GitLab (or one of the > competing platforms maybe; but mostly GitLab). I'm not sure we understand the practical aspects and consequences of this. At least I don't. Let's see what comes out of the list of issues I posted in my other message. I'm especially interested in hearing opinions of other active developers. > This time we already have a GitLab installation, as well as a few people > willing to work on integrating it with the larger infrastructure and our > workflow requirements. An employee of GitLab among them, which likely > means easier access to upstreaming certain features we'd need to make > this happen. It's a pretty sweet situation for us not to take an > advantage of, in my opinion. I certainly hope so. But still, IMO we should discuss steps we intend to be able to take soon, not something for the distant future.