From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.devel Subject: Re: On committing significant and/or controversial changes (was: My resignation from Emacs development) Date: Fri, 22 Nov 2024 12:47:22 -0500 Message-ID: References: <87ldxb9o3q.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007e0856062783fa31" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13934"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 22 18:48:43 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 1tEXlo-0003Rb-Tg for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Nov 2024 18:48:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tEXkt-0006Xx-CO; Fri, 22 Nov 2024 12:47:43 -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 1tEXkq-0006Xp-MS for emacs-devel@gnu.org; Fri, 22 Nov 2024 12:47:41 -0500 Original-Received: from mail-vs1-xe2e.google.com ([2607:f8b0:4864:20::e2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tEXko-0006C7-Nb for emacs-devel@gnu.org; Fri, 22 Nov 2024 12:47:40 -0500 Original-Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-4aef7d0cc2dso121356137.1 for ; Fri, 22 Nov 2024 09:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732297657; x=1732902457; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iwaT6v0mhgOlnC/Qmq4nFWEmc5k0MihDuOVQ+xSAfP0=; b=Vs4iTGEVlIROIe1roMcuDW7tY0qbmfZ29SPGf7TXEUkswmvWzfXTRbJ8L19ovg2TyB kaF1bAeXnDJVe/yLmrJTU9K2K/hCpxeyCI5jtppKPaucE0C0cqcBk3xYPR5cpY++wewa MPFKy0lOzhCs56dtoeDVtC1HO8g47YTbizbQ/jriwikW97YMjYi8/M55xwApSo9nObHf p8cGc7CZcfiy8tINcOGq+9FnOUgTBeWsOJqPFg4waf7YXGeo8syq3YXbYFvrMiTcPNDr c96bztRZr6OD+q79CwQdGwAmpv0z+17uPw97CG0WdBVIFjPCQrwfGJMFQEPGbRmyg8ws tIVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732297657; x=1732902457; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iwaT6v0mhgOlnC/Qmq4nFWEmc5k0MihDuOVQ+xSAfP0=; b=KzCMZT5u0PoqX/DePhPEsddUqJq7YSHinfHoXv1YeAsT3EJAyjw8Wi7TH/YSmaXvo6 X4QZRKogYHcaKmSnGv3HdF8W1BtypM7SFFg+KiHG6EU0JPjk3AsTY6PJ5e/EPjCTGjJQ 8HVDBhpW+cAR+5J5N3v5zfS8O/eaju869kgEa0aF3/GZmGk8Q2sQYp5x9Y4h/1Bgd/dq 8jnyp6RnAxHjL2/YJ10gjQz5JyiU35qQEYaE0WyF35KYZ1jpGyfU6DnVShm+V39MbJJC 1yW+15vN65/K9bcnpm1+v7lYOshb2KguHzZ1Zjvrwl/y8wBR7QOdPBCBqH3nRPTEHO6b 13Yw== X-Forwarded-Encrypted: i=1; AJvYcCUu0Zmwy8Zm87B7t4+muyn7D0XEWduZ9Axrs2RVRgQ8WmgFfrlnF+riU2++Fx2x5u73Y8kwjp6rovmL4g==@gnu.org X-Gm-Message-State: AOJu0YwuMIJyaLNlM26SsGeucHij2VtdK0YtQLVlWL1DB1gdDRSlvHHx TIAeKxkjoXV7A/Ha7ePSwMdj1Ev77ueEzZVklqSVeWUpXsKwz6tW0RsZCGrnZGc1ya44mOmSEOQ 6yly5m7V2+Rccuaqx+y5ap8Tf0avWVA== X-Gm-Gg: ASbGncsqRkSZ6ln5NPHno9vZsyhKPZefD6i174++OLWq48Mco6HVAkcBpROBjiWlzyM p2T16RC9sxSE0lyAMsO0J0nXPIRXKxo4= X-Google-Smtp-Source: AGHT+IFEKRzJZfyoIQG9BqU1QsbWEeKa+nr5C2CywHWN2iU+p3uR1jSz+Csfq1kSPSuNHs2hsPG5lWepwa+171uPN6w= X-Received: by 2002:a05:6102:508b:b0:4ae:f5a8:651b with SMTP id ada2fe7eead31-4aef5a86632mr2781217137.13.1732297657023; Fri, 22 Nov 2024 09:47:37 -0800 (PST) In-Reply-To: <87ldxb9o3q.fsf@localhost> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2e; envelope-from=shipmints@gmail.com; helo=mail-vs1-xe2e.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, HTML_MESSAGE=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:325596 Archived-At: --0000000000007e0856062783fa31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Considering how cheap git branches are, I would add that contributors could create a branch with their potentially controversial changes committed in the branch for people to better appreciate vs. users speculatively applying patches in their own private branches. I agree with your other suggestions. I remain a relative Emacs contribution outsider, however, despite decades of Emacs experience as a user, and as a developer in general. I greatly appreciate the level of discussion among Emacs developers vs. what I experience (despite encouragement) in the commercial and educational universes. -Stephane On Fri, Nov 22, 2024 at 12:25=E2=80=AFPM Ihor Radchenko wrote: > Alan Mackenzie writes: > > > I'm resigning my position as Emacs contributor. > > > > The immediate reason is that, as maintainer of CC Mode, CC Mode's > > symbols, its names, were taken by Emacs and used for other purposes > > without informing me, much less consulting me. That makes my position = as > > CC Mode maintainer here untenable. > > > > Eli Zaretskii and I have had extensive discussions, both in public and = in > > private email, over the last week or so, but we have been unable to rea= ch > > any satisfactory compromise solution. > > ... > > It looks like most of the discussion in the original thread shifted > towards personalities and specific example cases. I would like to create > a new thread that will exclude that part and instead focus on possible > constructive changes that might convince you Alan to re-consider the > resignation. > > AFAIU, there are two main issues you are annoyed with: > > 1. Large changes are _sometimes_ committed without notice or discussion b= y > Emacs maintainers. > > 2. When discussing controversial changes, Emacs maintainers _sometimes_ > make a judgment call and commit something without making it clear in > the discussion thread that the decision has been made. > > Would you re-consider if we somehow solve these issues? > > > Tentative proposal: > > 1. Make a rule that non-trivial changes and new features _must_ be > announced on emacs-devel at least a month (or week?) in advance > before committing them, and are only committed if there is no > significant discussion or after the discussion is settled > > If no announcement is made, they are reverted (temporarily), the > announcement is made, so that discussion has a chance to happen. > > 2. Make a rule that judgment calls are clearly indicated. If some change > sparks controversy/discussion and maintainer has to choose among > multiple solutions, such decision should be done in a separate, > clearly marked email, with a link to commit. > > WDYT? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > --0000000000007e0856062783fa31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Considering how cheap git branches are, I would add that contributors=C2= =A0could create a branch with their potentially controversial changes commi= tted in the branch for people to better appreciate vs. users speculatively = applying patches in their own private branches. I agree with your other=C2= =A0suggestions. I remain a relative Emacs contribution outsider, however, d= espite=C2=A0decades of Emacs experience as a user, and as a developer in ge= neral. I greatly appreciate the level of discussion among Emacs developers = vs. what I experience (despite encouragement) in the commercial and educati= onal universes.

-Stephane

On Fri, Nov 22, 2024 at 12:25=E2=80=AFPM Ihor Radchenko &= lt;yantar92@posteo.net> wrote= :
Alan Mackenzie= <acm@muc.de> wri= tes:

> I'm resigning my position as Emacs contributor.
>
> The immediate reason is that, as maintainer of CC Mode, CC Mode's<= br> > symbols, its names, were taken by Emacs and used for other purposes > without informing me, much less consulting me.=C2=A0 That makes my pos= ition as
> CC Mode maintainer here untenable.
>
> Eli Zaretskii and I have had extensive discussions, both in public and= in
> private email, over the last week or so, but we have been unable to re= ach
> any satisfactory compromise solution.
> ...

It looks like most of the discussion in the original thread shifted
towards personalities and specific example cases. I would like to create a new thread that will exclude that part and instead focus on possible
constructive changes that might convince you Alan to re-consider the
resignation.

AFAIU, there are two main issues you are annoyed with:

1. Large changes are _sometimes_ committed without notice or discussion by<= br> =C2=A0 =C2=A0Emacs maintainers.

2. When discussing controversial changes, Emacs maintainers _sometimes_
=C2=A0 =C2=A0make a judgment call and commit something without making it cl= ear in
=C2=A0 =C2=A0the discussion thread that the decision has been made.

Would you re-consider if we somehow solve these issues?


Tentative proposal:

1. Make a rule that non-trivial changes and new features _must_ be
=C2=A0 =C2=A0announced on emacs-devel at least a month (or week?) in advanc= e
=C2=A0 =C2=A0before committing them, and are only committed if there is no<= br> =C2=A0 =C2=A0significant discussion or after the discussion is settled

=C2=A0 =C2=A0If no announcement is made, they are reverted (temporarily), t= he
=C2=A0 =C2=A0announcement is made, so that discussion has a chance to happe= n.

2. Make a rule that judgment calls are clearly indicated. If some change =C2=A0 =C2=A0sparks controversy/discussion and maintainer has to choose amo= ng
=C2=A0 =C2=A0multiple solutions, such decision should be done in a separate= ,
=C2=A0 =C2=A0clearly marked email, with a link to commit.

WDYT?

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>

--0000000000007e0856062783fa31--