From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: My resignation from Emacs development Date: Fri, 22 Nov 2024 10:36:23 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38686"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 22 16:37:50 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 1tEVjC-0009x7-2W for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Nov 2024 16:37:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEVht-00017E-48; Fri, 22 Nov 2024 10:36:29 -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 1tEVhr-00016p-MP for emacs-devel@gnu.org; Fri, 22 Nov 2024 10:36:27 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tEVhp-0002Xg-Iq for emacs-devel@gnu.org; Fri, 22 Nov 2024 10:36:27 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5cec9609303so2543057a12.1 for ; Fri, 22 Nov 2024 07:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732289784; x=1732894584; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=FI8oKbGSdwMSZ1XkJ1gADNv2bqfivrr0pk90Z/1bDCI=; b=XcPR0h98d2xZUlIm8wHOdjBkuqS9pKjKzFM6kTHyNc0XtKT0Av15tkF+Q6LcluH+Pc 9FWpuF0RDyuTr1ghKr/TMqjLWOo7GRH9v9UNDp5HVSG0m0vJVOoyFBurS6p9kX5WNQF0 lPXenBStLZ7GndizDvmQrJTUkWxjWEGxt+6v/+g5M9lUBtDttU+arbJXa/RGWBhM1xmj 1YwzNegy9KYfqCTXObS+DAmMvUpyAycFuAslHVaxfTU3zpAUJ8/XMKJrD7CAc3JrwPBH czd1z3IOg5436XDWSxRMmMfMr4poAUrvnjM2AtDNqekW71jJiQOByV7PRI1kBrkmIOSB zTFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732289784; x=1732894584; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FI8oKbGSdwMSZ1XkJ1gADNv2bqfivrr0pk90Z/1bDCI=; b=A1mvy/mRa1c5abW4hf6cTZ/MwlJl5apu45+rl1UYpy2m06wtXG/+p3CCQz/+DHC+ly 1mxq1BeSg9gIOrKbxtPXx6zQgpNbk6f8at9g40F2vRazqJmyjo6THO6aGoTR6ohT+lrO 4kC4AMQORPgaJNYOrlREbwm9nVocr0zP/q3avVWLb4vWPE87h2hYFL/78zVZ0VBE8+sb g0k+QrLaPXgyBKrny77NRQ2vvkRBHxSAOV7b4Zs1cg9aBZwo7VUWD9kyR8c4/2BIcts4 E1fnzoqt8jYgoFERBAwDGy/m704m4wWV0qTAFlaDJNVlPM6pMnyAZdyC8rT6fqroITDa 5blA== X-Gm-Message-State: AOJu0YzO1AK6VAKm/8OfJWKrZTusRQQ6XA3Wso8Gh7c3Xw7xscqXOhhE mlZS3CdfgHE25l0TM/pHnp0FLLYcfzfJgYJYKGoYHuJ9wBU6CDvhvT56OfCxiwZ9M56nAyWj3sl gkr9BGIVhtFbNzjnzow3u77JG0RQ= X-Gm-Gg: ASbGnctnUeHiktID33OljhLQFmTl4yzHlHOWLVdJPSbO2x4U/DhCaKwOI0F0m5T5wsQ otCpBQy6Zc8qZ74+BPHm6htiPtQCI2xLQnw== X-Google-Smtp-Source: AGHT+IE3QmtXLkv1YIRsK8JPrDVJAZL/yPgvVUbpMrvxv05VoH/dyEEs/BklwK6bIXWYZEokzLB/fzxs6EUw6tb9CQE= X-Received: by 2002:a05:6402:4405:b0:5cf:e71c:ff97 with SMTP id 4fb4d7f45d1cf-5d020688616mr2713274a12.24.1732289783412; Fri, 22 Nov 2024 07:36:23 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Nov 2024 10:36:23 -0500 In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x533.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:325591 Archived-At: Hi Alan, Alan Mackenzie writes: > For starters: The change in the meaning of `c-mode' and `c++-mode' he > introduced in bug#69191, discussed at length in my last post. Stefan is > not stupid. He knew full well what he was doing in bypassing open > discussion about major-mode-remap-defaults. The patch was posted to Bug#69191 on 2024-02-16, received its first reply on 2024-02-21 ("SGTM"), and was committed on 2024-03-03, more than two weeks later. That all seems bog-standard to me. Meanwhile, the patch that you installed 1fdf0f68ccf0 was _not_ posted anywhere before it was installed, but it turned out to be controversial. Should you be condemned for that? Eli didn't seem to think so when he filed Bug#74339, and I agree. Some questions were asked, though. I also don't understand why anyone would have reason to suspect that you (or anyone else, really) would find the change in Bug#69191 so objectionable. I would never have guessed that myself, and the controversy therefore caught many of us by surprise. I still find some of the objections bewildering but would be happy to continue working to resolve any outstanding concerns. > Number 2: In late January 2024, Stefan decided to replace the customary > list form of interpreted functions with opaque atoms, because the list > form "annoyed" him. In the ensuing discussion, Richard described the > proposal as "perverse", and both Eli and I were asking questions as to > the purpose of the change. Only evasive non-answers came back. There > was certainly no consensus around the proposal. Nevertheless, Stefan > quietly committed his patch on 2024-03-11 in commit > f2bccae22bd47a2e7e0937b78ea06131711b935a. Emacs is slightly less > powerful as a result, in that macros can no longer operate on the code > of a function in a reasonable fashion. I disagree, actually. I recall a lengthy discussion with several participants that clarified why the change was indeed beneficial. I spent quite some time thinking about the issue myself, and also came to the conclusion that it was a good change, though I didn't have much technical content to add at that point which hadn't already been explained. Perhaps no one pointed out that using opaque function objects as we now do is already standard practice in both Common Lisp and Scheme; both are clearly examples of very powerful and capable Lisp dialects. I don't see that this change has made Emacs any less powerful. > Number 3: Stefan introduced pcase.el without any open discussion, and > proliferated it rapidly around the Emacs core, leading to confusion > around the use of ` and ,, certainly on my part. Now it can be argued > that pcase has been a success, but it could have been so much better if > it had been developed cooperatively. For years there was no adequate > doc string for `pcase', and even now the doc strings for things like > pcase-let* are woefully inadequate. Stefan is not good at documenting; > nobody can be good at everything. I submit that the reason why pcase has proliferated both in core and externally is that it is fundamentally useful. This proliferation is not due to a master plan concocted by Stefan Monnier (who, for the record, was an Emacs maintainer when pcase.el was installed). I'm sure that he did take the chance to use it to improve some existing code though, work that we still benefit from and can be grateful for. In practice, however, the decision to use pcase is typically made by the person writing some piece of code, and we cannot police the style of individual contributions on that level. That would make no one happy, and it would largely be detrimental to the project. So if people like pcase (or when-let, etc.), they will use it. What should we blame Stefan Monnier for? For implementing a novel feature that has proven both highly useful and popular? > Number 4: Some years ago, Stefan removed the documentation of defadvice > from the elisp manual without any discussion. Despite widespread > protest, he refused to put it back again. Quite coincidentally, he had > just written and pushed nadvice.el. We routinely remove references to obsolete or deprecated functions and macros in the manual. There is nothing strange about that in and of itself. In this case, I also find nadvice.el a significant improvement over advice.el; therefore, I think removing it was likely the right decision. (That said, I wasn't around at the time, so I didn't read the discussions.) Moreover, when nadvice.el was installed, and these changes were made in the manual, Stefan Monnier was an Emacs maintainer. Making such decisions, even amid controversy, is quite literally a part of the job description. Our current maintainers, I'm sure, have also taken decisions that some people have disagreed with. C'est la vie. We can certainly discuss changing our current development model and decision-making process. But for now, it is what we have. > Number 5: Previously, there had been an embargo on the use of the CL > library, except at compile time. This kept the size of the Emacs Lisp > language manageable, and the language easy to understand, and made > maintainers' and beginners' lives easier. You have raised this point in the past, and my impression is that few people agree with this sweeping generalization. I do not agree that our current use of cl-lib constitutes a problem. It is true that we could improve cl-lib. It would be even better if we added some of the more useful functions and macros to Emacs Lisp itself, so that we would have less need for a separate library. > At some stage this embargo was lifted, and the use of CL rapidly > proliferated through the Emacs core. Now, it could be argued that the > facilities and expressiveness of the CL lib outweigh these > disadvantages. But it was not so argued. It just happened. Maybe > somebody else but Stefan made this change, but it seems unlikely. Similar to pcase, the reason cl-lib has proliferated is that many people find it useful. Perhaps you may need to accept that you are in the minority on this issue. > I have not come anywhere near ad hominem. It is true that many forums > degenerate into slanging matches which repel decent posters. > emacs-devel is the opposite extreme, sort of touchy-feely where nobody's > allowed to offend anybody else at all, no matter what they do, why and > how they do it. This is just as unhealthy as the the continual abuse > forums; it leads to the build up of repressed resentment. > > Sometimes the truth must be told bluntly, and that is what I have tried > to do here. Phrases such as "Jekyll-and-Hyde character", "contemptuous of the Emacs conventions", "does not have the gift of knowing what the Right Thing is", along with terms like "monster" and asking us "what does that say about [him]", etc., are clearly ad hominem in my view. These statements focus on personal characteristics rather than on actions or statements made by an individual. >> 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 don't see that he has done anything very unusual or different >> from what most other core contributors do on a routine basis. > > This "be nice to everybody no matter what they do" and "always assume > the best of everybody" creates the perfect atmosphere for a monster to > flourish in. Stefan is such a monster; not all the time, not even most > of the time, but in doing the things detailed above, and other things, I > don't understand why you are defending him. OK, let's be frank then. First, I understand that there are things that you are unhappy about, and that is valid and to be taken seriously. However, I find your attempt to portray Stefan Monnier's character negatively completely beyond the pale. Using words like a "monster" to refer to another core contributor is just appalling, and completely uncalled for. Thus, I am standing up for basic decency in the face of what is more and more starting to look like an attempt at public character assassination, using harsh language (e.g., "monster") and enumerating alleged "mistakes" from as far back as 15 years. I urge you to retract these comments, and apologize. I have already expressed my opinions on the technical issues that you listed above. However, from a strictly procedural standpoint, I do not see that Stefan Monnier has exhibited a pattern of behaviour that stands out as culpable or even unusual within our development model. Note that I am not claiming he has never made mistakes, or that everything he has done is perfect. I am quite sure that he has done many mistakes, both technical and procedural. But so has every single person on this list. That does not justify singling him out, nor does it justify the attacks directed at him here. Please understand that the changes that Stefan Monnier has authored and that you find objectionable, in the minds of many other hackers are improvements. In my view, for example, he has done tremendous work to improve Emacs, and not least to make Emacs Lisp more powerful. The examples you give are some of the things that I would point to if I wanted to demonstrate that. --- Ultimately, all of us are volunteers who care deeply about our work. This means that feelings can sometimes run high, and that is understandable, because we are all human beings with different ideas, interests, and motives. Our team of core contributors are, despite our usually polite demeanor, a relatively rowdy group of strong-willed, and often opinionated individuals. This description applies to all of us; we wouldn't be running Emacs, let alone hack on it, if it weren't true. We are a small church, and it is in our best interest to collaborate. Precisely for this reason, especially when we disagree, we must make every effort to treat each other courteously and with respect. This does not mean sweeping issues under the rug, or maintaining some superficial peace merely for appearances. But it does mean that we have a strong preference for discussing the specific issues at hand, and that we ask everyone to meet a minimum standard, which we refer to as "kind communication", when participating in Emacs development. This is not likely to change. I sincerely hope that you reconsider your resignation. It is sad to see a capable member of our core team leave. Regardless of what happens, I look forward to continue collaborating with you in your capacity as CC mode maintainer.