From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers Date: Sun, 14 Jun 2020 02:23:53 +0300 Message-ID: <9e4d15f7-a6ef-1924-dcc1-00e256558446@yandex.ru> References: <87k12bdgx7.fsf@yahoo.com> <87r1wi7a8o.fsf@yahoo.com> <875zdteybt.fsf@runbox.com> <87368wrvf5.fsf@yahoo.com> <86k126d83n.wl-me@enzu.ru> <83pnbyckvv.fsf@gnu.org> <4923d7e98f5ed816a7569093dbc673153adcea88.camel@yandex.ru> <7e3969862c2d3f76fc812f4231d95e80e37c4c25.camel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="16098"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 To: Konstantin Kharlamov , Stefan Kangas , Eli Zaretskii , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 14 01:24:58 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jkFWE-00045x-I5 for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 01:24:58 +0200 Original-Received: from localhost ([::1]:56526 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkFWD-0006q3-In for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 19:24:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkFVS-0006DI-6l for emacs-devel@gnu.org; Sat, 13 Jun 2020 19:24:10 -0400 Original-Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]:38023) by eggs.gnu.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jkFVQ-0002aW-83; Sat, 13 Jun 2020 19:24:09 -0400 Original-Received: by mail-wm1-x341.google.com with SMTP id f185so11344728wmf.3; Sat, 13 Jun 2020 16:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v/VVpzhGt5Rpa9c9mZ5DdD/chcmIDmY1eBUtyqbM3+w=; b=T0KcjP9KN4Cyu84d4r08QkL/QvzNE8kWlDYKkq7iOS1MFzpUheeur0+fmMySkNZbNL WHZSscElhA8/WOJN7Qz0zvWCuR2/1w1PJV3xBqpptddEESVa53wNK8igEMnXdmYKAiap lmX8CgYr7YHasNWG6k0Klo0LioJwQZVruO/K20CT8IqQCaMkOkW3koLttXoO1i0FafEl Ow8SPxQ++kB3S/I5dt5kZAApLrrlPHpuzl/ilD7sFp6gTKcohAw1nZCWS8D6vSTtNKXA 7Bgng0xwqfgCzo41ZeEy7WbS/6B6zCMXtiH2uIoqufk1HRalT6Nv3G5nY/ADjFfGFtNb 5haw== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v/VVpzhGt5Rpa9c9mZ5DdD/chcmIDmY1eBUtyqbM3+w=; b=geifQLsFjdfXdE0R4dOqPftPjVs6VuGzoCpJtGx3FTzHy0yyVEbypJo0M9rHD/Xl6J +9WS/kFfyIDUhfEzYPjV8ARSgVBDAfVwipzJyX+0+IuVkyuPdu58F01exvafJdtVY12R v9ffo/wiROgLvIdd4EqxOJmq0IrkExLzQM2ThDMX6h40X66x7gNTc+EzoE7CowETw4B/ IYkNx3Zk80hvw2URgCaqLNi5Q2LAubvXG80+ftqKgDgc90DX6PvRHkw//JuAYVrAsOG4 KPzlQyQeNx3Fn/pz4r7ptD2HE/Ne0Wxs6RiB3/AdDPlBT9KPzlijzjnk9CQCOpmt4eqT 5Mjw== X-Gm-Message-State: AOAM5308Wws1RUUBEOSGEYOrGWdU6YF12Z13m8Y2NN4iWAjjH2o0xSUv LonDv73cuTduGgoJ0f/LC6V50ZR4 X-Google-Smtp-Source: ABdhPJxmxGyzJQ+HsU1m9U2uK6uEiXpnwkSc+r5/oA/LAcbFBV5J508l9HbbGGrSr6nOtd/Ii9OxOQ== X-Received: by 2002:a1c:2183:: with SMTP id h125mr5399220wmh.112.1592090635758; Sat, 13 Jun 2020 16:23:55 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id l17sm17011158wrq.17.2020.06.13.16.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Jun 2020 16:23:55 -0700 (PDT) In-Reply-To: <7e3969862c2d3f76fc812f4231d95e80e37c4c25.camel@yandex.ru> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::341; envelope-from=raaahh@gmail.com; helo=mail-wm1-x341.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252217 Archived-At: On 14.06.2020 02:00, Konstantin Kharlamov wrote: > So, they make a non-trivial functional change ("non-trivial" because here we > don't care of trivials like "rename a thing" or "factor out the code". These can > often be described just in the commit title alone), let's say, they replaced a > "list" container in a few functions to a binary tree for whatever reason. Now > we'd like to know why did that happen. We might want to know more things than that, actually. > In my case they clearly would not produce anything useful, they'll maybe write > "replace list to a binary tree" and that's it. Why? Who knows. Then I'll probably ask. If the preceding discussion, or the contents of the associated bug report, haven't made the reason clear already. > How will they behave in your case? Well, they'll collect the functions list, > then would scrupulously write an immensely useful information against each one > "Replace list to a binary tree here". You see, it is the same here. Let's imagine that I know that in the codebase 'list' is used in many places, and then in the ChangeLog entry I see that only some of them have been replaced. Then I cut the review short and ask about the rest of the places. Similarly if they actually described the reason the change, but the enumerated changes don't match that goal (e.g. some changes in some files are missing). Another concern that can come up are whether they added backward-compatibility aliases (to satisfy our backward compatibility policy), which should also be apparent from the ChangeLog style entry. Etc. > Sorry if I'm misreading, but given the context of comparing commit-messages with > the list and without, I can only interpret the "yes" as "yes, one sentence that > says the code pattern is factored out from all the functions is not enough, I > need a similar sentence to be repeated 34 times". Is there other interpretation > that I do not see, or do I get it right? Yes, as in "I'd have to review the diff anyway", and no, as in "I won't have to spend as much time doing it as I might have without the ChangeLog style summary". >>> If anything, it only burdens you by forcing to check that each function >>> is on the list. >> >> I usually don't. > > This! Strictly speaking, as a reviewer you should check it. If a contributor > forgot to add or remove a function on v2 of patches, and you passed them your > Reviewed-by, wrong commit message would partially be your fault. I'm all in favor of automated checks. Someone would need to implement them, though.