From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: My resignation from Emacs development Date: Tue, 26 Nov 2024 20:51:58 +0100 Message-ID: References: <169c6564-4722-4338-a049-5f8f3ce69394@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37319"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Porter , acm@muc.de, emacs-devel@gnu.org To: Daniel Radetsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 26 21:12:37 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 1tG1vI-0009Ul-5h for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Nov 2024 21:12:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tG1uc-0004B0-0l; Tue, 26 Nov 2024 15:11:55 -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 1tG1bX-0000WO-Cl for emacs-devel@gnu.org; Tue, 26 Nov 2024 14:52:11 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tG1bT-00052Q-RO for emacs-devel@gnu.org; Tue, 26 Nov 2024 14:52:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1732650718; x=1733255518; i=dimech@gmx.com; bh=9LTTlB/9mHUOZL8XtpCLCXkPAotjwC+f9W+3dJhiKVY=; h=X-UI-Sender-Class:MIME-Version:Message-ID:From:To:Cc:Subject: Content-Type:Date:In-Reply-To:References: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=I1FjaxOiT7M8cttAppOr7KrFRfqFezRwLIGsSjY46TixTkEBHn3DWCiBuh+Fg7ei 8OfYBO9WSkk5M/1DSFUFhiiCN7PJjZidS4WqfqJTArY6EajyoC/6WLrDA9kw/VpAz Q1N+Up/scVASSlLm8K51HjVS/JX7syMhI24YtelkmjvZiQbxyYB3WmXNLv9X2Dmdp yavmYaoePZ0Nm5LALxjE77mf3lL+VU4py2welLtt+mqQEFePCOMTinb4u7rwm0hsX YC1S9YBnQBa+akJGXIaJCphkEq3isvnymCCnyuvFxaC0cd6xOfY8UzGVwKBDFts6p 14YaayTA0adv1qf8aw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [77.71.252.27] ([77.71.252.27]) by web-mail.gmx.net (3c-app-mailcom-bs09.server.lan [172.19.170.177]) (via HTTP); Tue, 26 Nov 2024 20:51:58 +0100 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:itZ/wRT4sPGYE6vNll13AFKGbG/ucsBomSsCJ/C+uNMqIQ0al3khVU++gU8JZV6uwQwJO bwK4DEFmeyF5ff5GRkMgBt3KV1ITB9lnwGkGV1sSm5BNdZTCOt7DgDz88OCG6/+ESZ5WfXpk5XTy lwBDMfm0RGXn6oTnDewPI/ttgTLNxo+qlaZsuUzDF1g5MZTSk0ZF00CFl6c7uPDUql/9ZqT9HBzP EjiGOuKBgjm+akzCyz92K31z6KSDQW4c0xcdkn3/NqXL6ajzCJ1Sc7bs/jubUPL+LFNA8rlIQ8lZ FY= UI-OutboundReport: notjunk:1;M01:P0:k1T+z/VfPo8=;yK2Q9L5cgUfXE4m+bGJMfJEeGiu rraPg0v/vjAIiU4oAZbWyGeAUXOAgIKiv5sBHM6JOKaL88mIE/r8ZOnau9u+BuBc7+V8bkJCu 0+VEkH3K+UMgHJNSYIYCH5ddU7WRAy8CYjAnb6r/ULkYHrLXBAU+rdcXwG+1EH5ESig6ev9KT 05EZQK5zVK10LOALqvXTmW7/xDT8SofJPL+j974xNgqGzx7Y5kOzjOYlQDILuP20z50qGhLxu eV3DbPiZY40jZN4TwPzli8j9icnnA1bVBTZMsim36nZRJqCCYnW2Fr9lrqOd7cY8f/z3spjAx HWwMzYJNFxV4e8FQapQ+WAmFp8meqjo8dVLcBBfOBY0rJiPrVP1Q2mRdDs90qjjokGNP86DrY gS5QrjTjiXf3ujr+AueeY2wzPHX/WpZPwQkwwx271rSGUntVq8WhYObY7VWVqMC/NToFOx+cz 27eWkrxbZriTJgqbbdVkhQBfKxxkjNkQCi8RgMv3gRw47t8ftdDmZW4m0E24cIUIzwgeZDdAk cUJp7S5ShO5mEwHkUIUDXlsVa8TkHQJwt9jqNywIESmPhIuR9sx3YRniRP0tyFk42JGZ7LM08 CodgMzDCeWGoPXkO9gqhYxZPdrB3CNoEUeASzmb/j4c2m3xepzTfDs+WK3+dPljY/cNPENXKw YLEhhgxii/KTNM3F9v1g8Gz8OqsJ5uFXEm/RYYpjNQ== Received-SPF: pass client-ip=212.227.15.15; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 26 Nov 2024 15:11:46 -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:325724 Archived-At: > Sent: Wednesday, November 27, 2024 at 7:01 AM > From: "Daniel Radetsky" > To: "Adam Porter" > Cc: acm@muc.de, emacs-devel@gnu.org > Subject: Re: My resignation from Emacs development > > On Thu, Nov 21, 2024 at 11:35:35PM -0600, Adam Porter wrote: > > But it is not okay for you to blame Stefan for your decision to leave. > > I disagree. If he chooses to leave, and the reason for this > choice is Stefan's behavior or decisions, then blaming > Stefan seems straightforwardly informative. 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. 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. > I'm not as much of a veteran of this list as some of you, > and my few interactions with Stefan have been positive. So I > can't really speak to who's in the right and don't think I > should. But it's broadly better to have information about > what's going on and what decisions are being made and how > everyone feels about those decisions than to not have this > information. > > Basically, if Stefan made a decisions, and this made Alan so > unhappy that he wants to leave, this is something everyone > should know. Sometimes this is the price of a decision. We > need to know the price to make informed choices. > > I'm not accusing you of this specifically, but it seems like > in situations like this there's a desire to make the > situation black and white. Either Stefan made a bad decision > which ought to be reversed, and the fact that it is not > being reversed would justify Alan leaving, or Alan is being > unreasonable and thus his decision to leave is a foregone > conclusion being unfairly blamed on Stefan. Thus if we don't > want to reverse Stefan's decision, we must believe that Alan > is being unreasonable. > > But it's also possible that e.g. Stefan made a good decision > in the big picture, but this was locally problematic for > Alan. And even though we prefer Stefan's good decision, we > prefer a worse decision with the benefit of Alan's continued > contribution than the alternative. Or maybe not, but this is > why we want to surface the costs of decisions. It's better > than pretending that hard decisions don't need to be made, > and that the true costs of those decisions are just somebody > being unreasonable and thus not worth counting on the "cost" > side of the ledger. > > If Alan isn't happy with Stefan's decision then even if we > think it was overall a good decision, this doesn't mean we > have to be unhappy with Alan. We can just ask ourselves if > the whole thing is worth it. Or rather, the rest of you can > ask it; I don't have an opinion on the specifics. > > --dmr > >