From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: My resignation from Emacs development Date: Tue, 26 Nov 2024 20:18:17 -0600 Message-ID: References: <169c6564-4722-4338-a049-5f8f3ce69394@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31576"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: acm@muc.de, emacs-devel@gnu.org To: Christopher Dimech , Daniel Radetsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 27 03:19:29 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 1tG7eK-00083M-Mg for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Nov 2024 03:19:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tG7dM-0005vU-Ko; Tue, 26 Nov 2024 21:18:28 -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 1tG7dK-0005vE-K9 for emacs-devel@gnu.org; Tue, 26 Nov 2024 21:18:26 -0500 Original-Received: from cyan.ash.relay.mailchannels.net ([23.83.222.47]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tG7dI-0005Ky-I8 for emacs-devel@gnu.org; Tue, 26 Nov 2024 21:18:26 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 349B11C1C2D; Wed, 27 Nov 2024 02:18:21 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a280.dreamhost.com (trex-8.trex.outbound.svc.cluster.local [100.127.102.36]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C5AE21C1CEF; Wed, 27 Nov 2024 02:18:20 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1732673900; a=rsa-sha256; cv=none; b=5mnT4Xted6heBzSrtx0YnAL79y2dOM0GlkKiCYFGbvrrp5Ogd64t+TXUbMlEjwEkpdd848 cpffrYIHdX8r5vyXFh0T6sSv0q24coWNDIdVufjUkkV62DfdpsBQYuKWf869TQc6m37Eh9 57Xgiq3n+XhbkDEnS2BkGoA5qI8LYnyslBpwoJ7bVKi+FDQManOGjvyZjqfumX2Ru1DBmm OH9IsEiIbIsgoxEUPi+6K2mKALtaA0WlHUl7tOMtJIuycl4gvPuPQkf6q4GH0NZJkznf6w vU8K3f32KVYz0476SuMO+hRqM8RtNB0eNSzhKDqfGH5ABoc42PObH8CPFafhdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1732673900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=A+AlYYHT2v2xsYWxXSZISe8cblutE4UCNRZgLUOC1yo=; b=Lbn2IPdvUnYyBjilTN1QSWA/MzwAmocoRPYlIruPBFseTzG3ekzo4ZEevIi7e+1aNa36e3 cOJ9ypgPpCrjJ0jEgtqBPBqU6aM+4kX9+bVN9H1i6MVtIY5rMRlor6teleDONyQyQsVlqK qykT0m+x0oe4CSQnbwMHktkssoHKkg6lweB16KLGfSphtWN0S+2Yb/Fv0IsjnI9H+/t2GE Rqwx99alzJEsBjGtHNVY48ih85hRSeK0gMVUnwmD5+PWOvFWAsZBIU6iTgAeHDZax7tLLZ 3AyQmmIr8xzV+/ztNGWLsxO7EmQfSYqU+RGAdKNM4Mpf2lZS/EX1nocVeVc0Vg== ARC-Authentication-Results: i=1; rspamd-dcc6979f6-w6vfp; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Interest-Unite: 5966b06f37a42b29_1732673901045_1300128104 X-MC-Loop-Signature: 1732673901045:3010541341 X-MC-Ingress-Time: 1732673901045 Original-Received: from pdx1-sub0-mail-a280.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.127.102.36 (trex/7.0.2); Wed, 27 Nov 2024 02:18:21 +0000 Original-Received: from [10.43.29.237] (unknown [193.56.116.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a280.dreamhost.com (Postfix) with ESMTPSA id 4Xyjlv4VQcz2n; Tue, 26 Nov 2024 18:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1732673900; bh=A+AlYYHT2v2xsYWxXSZISe8cblutE4UCNRZgLUOC1yo=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=GnOtv6HF6em7Lc+ag+agnMOsdwfSVn78p6SKGiTIE9oIb93o6ZILu6zFcrorGZ0WM OhX1J6aq2SEXqUDc7NC0vTV6tieNXMyFYdDh34wmvEBw2hRjPplyO0TNBV8TEX79iA CWuATKB9TrYT+k7/zkM/f+dP033ZCj/Bx68o2TuQuwrkBPkf+zq78j+qxvr6jOYcLu OrjUT6dlJGXFOD+fI2H1/5lDpla7UtpAXNg2qzn6bTKWVWvkWG4/c2u/vHruPsJlZn wNNrXl5Vckt7pzYZhA3nmmMYMVvTq66Cf1sDDOlddnbiEpR22wsIy4BdMhaI0HiNc0 4MKJRl1p+X/3Q== Content-Language: en-US In-Reply-To: Received-SPF: neutral client-ip=23.83.222.47; envelope-from=adam@alphapapa.net; helo=cyan.ash.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action 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:325732 Archived-At: Christopher, On 11/26/24 13:51, Christopher Dimech wrote: > In the matter of blaming maintainers for decisions - whether directly or > indirectly - the question of whether maintainers should be allowed to > break their own rules is critical. A compelling case exists that they > should. Strict adherence to lengthy review periods or > consensus-building processes is often impractical, especially in > situations where only maintainers possess the necessary expertise to > advance the program. > > Maintainers breaking their own rules represents a pragmatic approach, > prioritizing progress and functionality over rigid adherence to dogmatic > processes. This flexibility ensures that the project continues to evolve > and adapt to its challenges. You seem to imply that some kind of rule-breaking has happened. I don't think this is so--unless the rule were "No one may make any change unless everyone agrees to it." The technical matters in question have been thoroughly discussed. A change was made. The maintainers support it (in absence of a better solution, which they have not found). One contributor refuses to tolerate it--regrettable, but solely his decision to make. There's little else--factually--to say. > That said, while maintainers must retain the ability to make such > decisions - even if they sometimes result in dissent or the > departure of contributors - there is a clear responsibility to avoid > fostering a culture of arbitrary rule-breaking. Transparency, > accountability, and judicious use of this authority are essential to > maintain the integrity of the program, especially in a collaborative > environment heavily reliant on contributor involvement. You seem to imply some kind of secrecy is involved. Everything I see indicates the opposite: lengthy, public discussions, long-considered but finally needed decisions, and further lengthy, public discussions (with unfairly implied chastisement of the maintainers for implied secrecy). One could hardly find a more transparently run project. You even mention integrity, as if to suggest that the maintainers' is in question. Please be careful that your words don't imply criticism where none is deserved. --Adam