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:06:53 -0600 Message-ID: <02970060-167c-4da1-8e6e-e94fbee8bdc0@alphapapa.net> 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="34776"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 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 Wed Nov 27 03:08:09 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 1tG7TM-0008ui-Hh for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Nov 2024 03:08:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tG7SR-0003Ls-Mt; Tue, 26 Nov 2024 21:07:12 -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 1tG7SG-0003LI-CU for emacs-devel@gnu.org; Tue, 26 Nov 2024 21:07:01 -0500 Original-Received: from seagreen.cherry.relay.mailchannels.net ([23.83.223.160]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tG7SE-0001S2-Js for emacs-devel@gnu.org; Tue, 26 Nov 2024 21:07:00 -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 E42E6942FA2; Wed, 27 Nov 2024 02:06:55 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a280.dreamhost.com (100-121-72-155.trex-nlb.outbound.svc.cluster.local [100.121.72.155]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7A7E5942F39; Wed, 27 Nov 2024 02:06:55 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1732673215; a=rsa-sha256; cv=none; b=3boWJ7ULr6ktqvpfBWhimxKSEbyHMcm91tNt3GYqvjr3Ovz+Q09fL09CR8cg5YH3PdZLQ4 UhBIJ/6zeqHF/L0d2J46G8FXZDGds5RUyMpYLIPA0BlMgVbtwKjzIemyLuDFrp03+ytMkg ug7wF0vksgFN+MD963CDJ1x8SrpLAUe1oakmftaGfmUBe3IlS9wM6fJjVDvQvnYCF8iiBt Tb3Xlrkli/tv5yu1ab/mTWMqimxYfZhtWiqruhTF3TAMSwCaB1LwdfByqmCYIF54zdY6XI 2W47HFdLpz6e2Jju3UlPkPxw1y5Kw+NYfEBeKPJ5LkLBumGsD8Vc5zGwA0CL3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1732673215; 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=63GjYtogI/SDaBu5JHkoV2dY2BFLWma7kil3USwmnuk=; b=Ib35Y2oFQ3KaS7CZn5HcyTRCuweIEYgiUgtgDiWU4R92qfN1kq9KmUT6r1+HD+2PU3d6h+ VwaDFvLO9xXR5NTCHKJkoqcTot42WeqZzvjCRgcPLaLASkvgDkc1EbLLek201vvgjG8xEl TlJAsWqHKywj/QEwEya5ilGpTGTdN9Rnh05lcplW9RnnulnebDu2kAeBUzY5n2lMcghNO9 5agedehP77mfs5Htys0aA8ZQC6qlNaXWARjYJCSk4sfH2WeFtiVr2UTV2djG69xcgkhGI2 40/eqvJu0enJnuM0kS5rCcdB/j7G1NIaOgX3EZPz6eUVpbTclcNQUZwJBDZOBw== ARC-Authentication-Results: i=1; rspamd-dcc6979f6-8q8lb; 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-Spill-Left: 36f621f45a1e253b_1732673215743_1122777567 X-MC-Loop-Signature: 1732673215743:2773893933 X-MC-Ingress-Time: 1732673215742 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.121.72.155 (trex/7.0.2); Wed, 27 Nov 2024 02:06:55 +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 4XyjVk6Q7lzFN; Tue, 26 Nov 2024 18:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1732673215; bh=63GjYtogI/SDaBu5JHkoV2dY2BFLWma7kil3USwmnuk=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=W2Rhvg7MtYWPO8ikPSA80r4nC+AOYwM/HzB8ssgtQCKDGK2Q+L9DV3UyZ1lEmwmT7 cpxt3Mtwi+WqEA3nhGORmjGS/VY/At1Ngro75z0BYlJBlNTaKE+UTbLdVhqQlj1J4W WzJ+6hbmZJnfZ7XRJmOu6pnVVKpsERyhNgtYONCWh0Pcane1yJvkxjcKV9skNlnkap 84yTsYzzgCo4uajwKca1IACe1lehVK+GTrp0MyXuseqlr8UDtSP5wrZFlOnQ1m0sa0 j18fKAM7Y0iTYDizVUrWR5OhghikVSiue7q/5xo6jqIFophbaQRGMoIUPWNhlxfjN0 h5zscsrEEufGw== Content-Language: en-US In-Reply-To: Received-SPF: neutral client-ip=23.83.223.160; envelope-from=adam@alphapapa.net; helo=seagreen.cherry.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:325731 Archived-At: On 11/26/24 13:01, Daniel Radetsky wrote: > 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. 1. As has been clearly stated, Stefan is not in charge of this project--the maintainers are. Any change made by anyone, including Stefan, only persists with their approval. So to blame Stefan is to imply a responsibility he does not bear, which is unfair and wrong. 2. As has been clearly stated, the technical matters in question have been discussed extensively by the maintainers, and the status quo appears to be somewhat of a compromise, an approximation of the best that could be done given the circumstances and the timeframe. It doesn't seem that anyone is truly content with the current implementation, yet no agreement on how to improve it has been reached. So to blame Stefan for an implementation that even he is not fully satisfied with, yet no one has been able improve upon with consensus, is unfair and wrong. 3. As has been admitted by Alan himself, he made a relevant change without discussing it first, and one that apparently forced the hand of the maintainers to deal with. That would seem to imply his own having committed the same kind of misdeed which he accuses Stefan of committing. So to blame Stefan for an action which Alan himself has taken, in the same context, even, is unfair and wrong. > 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. You seem to imply that this information has only now been revealed. As has been clearly stated, these discussions about the technical matters are not recent, and they were primarily conducted in public. You can review them and come to your own conclusions. The only new information here is Alan's recent decision to stop contributing, which is not a technical matter. > 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. Alan's feelings about and reaction to these technical issues are Alan's concern. If he chooses to make them public, that's his decision, but it doesn't necessarily make them our concern. Disagreements about how to manage a project like this are common, and they needn't always be made public--especially, they should not be in the form of public character assassination and ritual defamation. > 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. You imply circumstances which are not so. See earlier paragraphs. > 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. I don't think that any project ought to govern itself by acceding to "my way or the highway" demands--what could be more unhealthy. > 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. Respectfully, it seems like you have spoken without fully informing yourself of the context. This whole situation is very simple (not being a technical problem, though originating in one): 1. Stefan made a change, 2. Alan doesn't like it, 3. no consensus has been reached on how to improve it, 4. the maintainers don't think that reverting the change would be an improvement, and 5. Alan has decided to cease contributing. All of that is fine, though Alan's decision is regrettable. What isn't fine is to misplace blame on Stefan, for a decision that the maintainers themselves support, and one that no one is fully satisfied with. All parties would be well advised to set aside ego, territorialism, and grudges, and seek the best of the project, which is our common interest, the reason we are here. Technical problems can be solved, and social ones can be forgiven--if the parties are willing. But each one must decide for himself. And once a participant has made his decision, for the good of the project and its participants, he ought to stop publicly litigating it. And any outside participants who feel a duty to offer their input ought to do so with the utmost care, and only after fully informing themselves of the context and all parties' views, lest they only throw fuel on the fire. --Adam