From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Thu, 25 Apr 2019 13:35:01 +0300 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> <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> <83sgu6zbfe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="179387"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 25 12:36:05 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 1hJbjV-000kJr-5E for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 12:36:01 +0200 Original-Received: from localhost ([127.0.0.1]:55044 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbjU-0000D3-4e for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 06:36:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbij-0000Cn-O0 for emacs-devel@gnu.org; Thu, 25 Apr 2019 06:35:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJbih-00073X-Kh for emacs-devel@gnu.org; Thu, 25 Apr 2019 06:35:13 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:39269) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJbie-00072R-Im; Thu, 25 Apr 2019 06:35:09 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id n25so9802893wmk.4; Thu, 25 Apr 2019 03:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7St0RV+JvyL56bXwu1FGNFNwJ/K8j4bVpNdgw3EjZ6M=; b=tJGbIbvGxs12fi3HEFrzC4kHMQY8NDwwCFTmCvO4/dqUVQ2VB50mF58HR6U+WjS62J iGb3UhuHaz2cnHDP8yz6XIQnJd5Ch05fztlu/k5pIWNq88RaBisGAVH9o4+0xxNsgg8A n0nByroqAvdHYAfQ8t/nIsWMRrorJBSERtUYVCgs3xjmRiltOe6+25XP2MiLmkFKfgg5 5uDt1o5KiIrrzD2A8IpkYUqe4KkIA6+maCQvWLaWSREu8ulHuosntoh2wOSIiAejcaZB N03Cj0TCcq6MHHT4IngTXuXGvfpYWbSpSPVuwIp7vThMJv2p4oQ6MbNLn1E25/N5Epqg g99w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7St0RV+JvyL56bXwu1FGNFNwJ/K8j4bVpNdgw3EjZ6M=; b=FlEYsLxqgu6//BQed+4vu9T+eIEYUNMauFk+DgD86Wv1+v2WY+zz/NCkGG0giRNL+L k8M5eky3oA4IkFWz8LT3WWs9SGClqNGCAn6IjWbz1lZJr9HA0+GGHiH/2ctBPaG2EjAy gB1g7ymfSRg2uZOUE+IGIVJkyZ3jx8V3Of2ex4OHN7RNBfsV+yUQI5C2k59Ykao/4aGN ghzKAM/VvSV/tI2p+S3e4obYXC1PwVouqUF5AB8OCDVUXGr+9KdyKtMGBmpaPk/eGYO/ mzk8IcfEixhGufvKo6nldxhvrHbfjpYdRha4LmE415xkOaz37nHNvY1EYSx/PnFwv3k0 r2Xw== X-Gm-Message-State: APjAAAUIwszFveA/ttG7Yuvn/rQasjI4jQhU6i5m1S9F87CePZfEzwMc G6IkFC58dUsYpXJtW5X0saN0K/0v X-Google-Smtp-Source: APXvYqwS6u7iL8KxAor9vRUy+Cksknl3tlsuHV9XLcxsvAgTOu2cnyj3XOCA3jkQ/AbubeUsAUQFYw== X-Received: by 2002:a7b:c417:: with SMTP id k23mr2829637wmi.123.1556188504666; Thu, 25 Apr 2019 03:35:04 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id r196sm20654158wmf.22.2019.04.25.03.35.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 03:35:03 -0700 (PDT) In-Reply-To: <83sgu6zbfe.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::334 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:235913 Archived-At: On 25.04.2019 12:22, Eli Zaretskii wrote: >> 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. True. In the past, I have reviewed patches in the areas I knew little about. The process mostly consists of asking lots of silly questions, and if the reporter is patient enough, that can get the patch approved, and the reporter can indeed become someone who takes care of a particular feature. That's the optimistic side of the coin. > 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. Sure. > 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. That is exactly the change in the tone of this discussion I've been hoping to enact. > 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? You mean only after that we can consider changing workflows? A lot of big, popular projects (and especially those) have huge numbers of untriaged bugs because it's simply a function of a project's popularity. I honestly do not know what improvement is possible with our current resources. The only way I know of improving the situation is to try, and try, to attract new contributors. And that can happen if we use newer tools which increase visibility into our development process, and makes it more approachable for a new contributor. >> 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. Much as a like my opinion being heeded, and even the lack of expertise aside, it's simply not possible for me to rival the amount of effort you are putting into the project. Not in the next several years anyway. So I'm really thankful you are doing that, even if I don't agree with some decisions. Hope you know that. >> 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. Well, not sure what examples you're expecting, but I've picked up some features that others started work on (ruby-mode, xref, project.el). And the work on the NS port, for instance, has moved between maintainers several times on my memory. >> 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. Let's! >> 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. If you look back at the list I wrote, only the step of Migration off Debbugs (the last one) should be considered distant.