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 04:06:28 +0300 Message-ID: <5161ae04-391e-49d8-e942-127c04062c27@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> <1553064994.13109.0@yandex.ru> <831s32t3fn.fsf@gnu.org> <93f38b88-059b-b243-49bf-df61f424fb3f@yandex.ru> <83o94zap79.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="74872"; 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 03:06:54 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 1hJSqk-000JKw-7A for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 03:06:54 +0200 Original-Received: from localhost ([127.0.0.1]:49394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJSqj-000595-2r for ged-emacs-devel@m.gmane.org; Wed, 24 Apr 2019 21:06:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJSqZ-00056n-Qd for emacs-devel@gnu.org; Wed, 24 Apr 2019 21:06:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJSqU-0001ae-Fs for emacs-devel@gnu.org; Wed, 24 Apr 2019 21:06:40 -0400 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:36624) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJSqS-0001XS-DP; Wed, 24 Apr 2019 21:06:37 -0400 Original-Received: by mail-wm1-x329.google.com with SMTP id h18so7780660wml.1; Wed, 24 Apr 2019 18:06:33 -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=O+2WhMr3pd1xRGnYr5UsX6JCu0Gb9Ub65Ro/iCjVz1c=; b=aerKpgN3msrQ3AxbyI5y5kN+fylu1D2cAi+B7/hGUuyVw+obinXDiQAM9ZzRX4M30h BuERwAnYI8VowEv1m7HB6p5cCJd7C8EueJEyWGmH08Qyiv14vW3kEv5olu+mXwBzquB2 4n61vsFqBlh2WsluZF4rxJu+D+Rfo6+ifMNMPN1rd1fhVG1asnQCeKS7JrM2OV7AV3kR fXHg8lpv1IFxk9JuV127/Obc5hhM6zsQEshmTqp8GMIiyMUn8Xu8eY1ZY4rIxxGB+DEm Ci1O0LV1sbVI0gX1DwvklHSFtYMuw5pN4TLD5xEN32cvJQ7OuPmBUnv/C/jKdDCjdyKS rjtQ== 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=O+2WhMr3pd1xRGnYr5UsX6JCu0Gb9Ub65Ro/iCjVz1c=; b=NvTCQoNVHSZRMyptEPRqifXyEW5PMHjcnjxaruTxtFP4oPUhU7CQvnmlvW5piyEVEP ZWubJ/6HlAgTQ/8s/pr7t6KDHgrlAvwlG8yKV7hE8GG9CRm3kdpPMWJ67hEqmr0P8Ism cUguQIwb92bHRQlG1f8psnyLtxm2icPYU1hRRyJ6gtjWmqV+kDhbyTVyljuLfp1VlGTF BcM1sTrtkZekKcmKreieuqZYeZkKawZtG7dpOdWrWhZdTbr+ljiwQdj+fnvzRfbmT0jQ gvET3pZwLWm9onPBcTtFC4s2rVtCCkNT276r8NvVsc/BRkOrREjik8Q0gRbelCIMXE54 f+2g== X-Gm-Message-State: APjAAAVLqZDYnjhqiHpfSANBAAu+uTroCTpQunEHGBGcyMAWjdFe+Jq6 8/aUqWNGv+/GpceHFa5SVpUUGRPK X-Google-Smtp-Source: APXvYqzzDfdtHbjPVIcz4dUAL8JTptTxslyUzxslNObjyBgOgIk2tHUgL+iNOm9dvpwTyjltI//vag== X-Received: by 2002:a1c:eb03:: with SMTP id j3mr1322512wmh.15.1556154391600; Wed, 24 Apr 2019 18:06:31 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id z13sm14138806wrh.41.2019.04.24.18.06.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 18:06:30 -0700 (PDT) In-Reply-To: <83o94zap79.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::329 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:235895 Archived-At: 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. That is probably inevitable as well. The most essential ones will find their contributors. > 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? > Are you using the debbugs package from ELPA? If not, I suggest giving > it a try. I've been around for a while, of course I have it installed. Since I don't have SMTP configured in Emacs anymore, though, it's become less useful. It cannot paper over all deficiencies of the underlying platform either. But it's good that we have it, of course. >> On the other hand, discussing the possibility of a migration and >> agreeing on some specific goals can encourage people to get more >> familiar with Emacs development workflow, even as they try to improve >> it. Which can increase the pool of contributors as well, by itself. > > 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 somebody offers to take over as the maintainer? (I'm hoping for a "no" here). I'm saying it's better to encourage the possible contributors to bring their own enthusiasm and expertise, even for a while. Not every unfinished project is a loss. Someone else can come along and continue it. 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). And that doesn't mean you'd have to settle for a completely alien new workflow that you would be uncomfortable with. Even when we discussed bringing over GitLab as a code review platform the previous time, we talked about existing Emacs packages that provide access to the features of the platform, as well as writing our own if the existing ones turn out to be inadequate. That's still feasible. > We could discuss that, but it's IME futile to talk about the parts > that are too far in the future, because when we get to that, both the > people involved and the technologies will change. So talking about > those distant parts just facilitates long discussions with no > conclusions. We have past discussions to serve as examples. The past discussion on a similar subject was relatively different, in that none of the people involved had both the interest, enough free time and expertise to see the project through. 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.