From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: My resignation from Emacs development Date: Sat, 23 Nov 2024 09:48:46 +0200 Message-ID: <86o726mlup.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5410"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 23 08:49:55 2024 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 1tEktv-0001EB-4E for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Nov 2024 08:49:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEkt6-0001a2-FW; Sat, 23 Nov 2024 02:49:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEkt5-0001Zr-0h for emacs-devel@gnu.org; Sat, 23 Nov 2024 02:49:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEkt4-0000m5-3L; Sat, 23 Nov 2024 02:49:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Xe6vlmMvv9AVQ8OLA3klRTIVX2ZVydRtdTMMefK0km4=; b=fJCGV+FGtmdY LsMdL3S0AbG5CyEHfmvYu8k8lUptYw2xcjQwZb0Z8Ny81j6yogxiqewvB06J0qG3F1vIqjIhv9sIy H6RhQF3z9gpCeQH2fn6/mL1oTsosHfA0pAxLOtM+7jsEc3HLb2tR33X2zBNqBgt6C/7RrbYgwQY73 v9SEOGPPs941BazLd1sSBce3YZcaw1DB9XDAf32sjI7HmIr8n+VWDoVhaWHwQSEZCppR/25ER5x57 VdLSIfO2XyAQKFCiIeV+jJtfrIknMS0LiKC6NtnaNc/KuCAW73CVHCjbHKOSoMAznVHAKfYVw61R7 RUqyvYLFccuZWq+CZK05Tg==; In-Reply-To: (message from Richard Stallman on Sat, 23 Nov 2024 01:10:42 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325607 Archived-At: > From: Richard Stallman > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Sat, 23 Nov 2024 01:10:42 -0500 > > > I have to agree with Eli. Although it would, in hindsight, certainly > > have been better to discuss these particular changes in more detail in > > advance, > > I too have complained that major changes were not being discussed in the > way that they call for. My impression is that complaints about "changes installed without being discussed" assume that discussing them would have stopped them from being installed. When there's a chance that this is the case, according to the best judgment of the maintainers, we insist on discussions (at least I do) as prerequisite for accepting the changes. There are enough changes which were rejected this way. However, as I've written elsewhere in this thread, Emacs maintainers are just stewards. They don't "own" the project, and cannot dictate their preferences when some change is widely favored by the community, not without good reasons, which are considered "good enough" by the community. So when we feel that a change will be widely supported, regardless of discussions, we see no reason to delay its installation. (Of course, code review and various minor issues like proper documentation etc. are still in effect, and many times require re-submission of patches before they are installed.) > I think this incident shows that we need to make a rule to ensure > they get discused properly. Some ideas occur to me, which could form > a part of this. > > Here's one possible approach that occurs to me. > It's not the only approach that could be good. > > * A new feature must be brought up on emacs-devel with a clear description. > > * If anyone on the list says, "This feature calls for careful discussion," > then maintainers must respond saying, "We will now have 14 days for discussion > of this feature." > > * 14 later, a maintainer can post, "We have had 14 days of discussion for > the feature XyZ. Here's how the plan stands now. Does anyone call for further > discussion?" > > * If anyone on the list says, "This feature calls for further > discussion," then maintainers must respond saying, "We will now have 7 > days for further discussion of this feature." > > * 7 days later, the maintainers can install the feature. We already have those rules, albeit not formally. But rules are not always followed to the letter in a community such as ours, and we have no real means of enforcing them. (Extreme examples of disregard for those rules cause radical measures like public harsh reprimands of the offenders, and reverting of the offending changes, but that is a doomsday weapon that must be employed extremely sparingly. And we have nothing else except telling people a-posteriori they should have known better.) I object to codifying such rules, for two reasons: . Rules that force people to behave decently and respectfully to others send a message that people are not trusted to do it otherwise, which, to me, smells of totalitarian societies and by-default incrimination of people we know nothing about. We have Gnu Kind Communication Guidelines where other projects have the notorious Codes of Conduct, for this very reason. . If such rules are broken, we have no real power to do anything. IOW, the "or else" clause of any such rule is basically empty. The only measure we have is to take away their write access, which is again a doomsday weapon, and will certainly avert contributors if applied when, say, some change was installed without waiting for 14 days. Beyond the above, I personally have no will to enforce such rules, and if the decision is to introduce them, someone else will have to do that, because I will not. It is against my vision of how such communities should be led, and no one can ask me to do this job against my principles and my best judgment.