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, 21 Apr 2019 08:43:06 +0300 Message-ID: <83o94zap79.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="117572"; 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 Sun Apr 21 07:43:31 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 1hI5GE-000UUx-RH for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2019 07:43:30 +0200 Original-Received: from localhost ([127.0.0.1]:49215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hI5GD-0008SK-Id for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2019 01:43:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hI5G5-0008SE-5v for emacs-devel@gnu.org; Sun, 21 Apr 2019 01:43:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hI5G4-0003YO-KI; Sun, 21 Apr 2019 01:43:20 -0400 Original-Received: from [176.228.60.248] (port=4525 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hI5G4-0007wT-1B; Sun, 21 Apr 2019 01:43:20 -0400 In-reply-to: <93f38b88-059b-b243-49bf-df61f424fb3f@yandex.ru> (message from Dmitry Gutov on Sun, 21 Apr 2019 02:26:44 +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:235726 Archived-At: > Cc: theophilusx@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 21 Apr 2019 02:26:44 +0300 > > On 20.03.2019 9:23, Eli Zaretskii wrote: > > > Unlike in many other projects, I consider the situation with patch > > review, and more generally with the number of domain experts we have > > on board in Emacs, a disaster. > > Personally, I expect a lot more packages to be retired or moved from the > core into ELPA in the future, perhaps tagged as unmaintained. 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. > > Recent years saw a lot of change in Emacs infrastructure and > > maintenance procedures -- we moved from CVS to Bazaar to Git, we > > removed some of the obstacles to newcomers, such as ChangeLog files, > > we codified the most important parts of the procedures in CONTRIBUTE, > > etc. This indeed brought welcome new contributors, but the growth is > > very slow, and the impact on the patch review process and on the > > number of people who are proficient in core parts of the internals is > > still very much minor and inadequate, IMO. E.g., the backlog in patch > > review and in solving reported issues is still unsatisfactory. > > You're mentioning some changes, but the patch review process itself has > changed very little in the last... how many years? 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. > And speaking of backlogs in patch/bug review, I'm personally unsure how > many bug reports and patches are out there unattended that relate to the > files that I maintain. The tagging system is barely adequate, and every > time I use Debbugs I have to rediscover it (as well as search, with its > bugs) all over again. Are you using the debbugs package from ELPA? If not, I suggest giving it a try. > > People who want those infrastructure changes should become more > > involved, so that we reach the critical mass sooner. > > People work on what they want to work on. Even if they somehow feel more > encouraged to contribute, not many people are going to work on arbitrary > pieces of Emacs, or review random patches. > > 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? > I think it will be helpful to outline and agree on some rough migration > plan which can be enacted. With steps and conditions for the "people who > want" to know what to work on. 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.