From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: On committing significant and/or controversial changes Date: Sun, 24 Nov 2024 10:26:09 +0200 Message-ID: <86mshpjavy.fsf@gnu.org> References: <87ldxb9o3q.fsf@localhost> <86y11bm6oq.fsf@gnu.org> <87ttbx73zu.fsf@> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29652"; mail-complaints-to="usenet@ciao.gmane.io" Cc: shipmints@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org To: =?iso-8859-1?Q?Bj=F6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 24 09:26:52 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 1tF7xD-0007YI-Vx for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Nov 2024 09:26:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tF7wf-0007Gw-Jf; Sun, 24 Nov 2024 03:26:17 -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 1tF7wd-0007Ga-T9 for emacs-devel@gnu.org; Sun, 24 Nov 2024 03:26:16 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tF7wc-0005qs-AF; Sun, 24 Nov 2024 03:26:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3OoaaTBJhQgMayTDx5xfPUjJ4V1LceplV2P89+bYE7w=; b=q+CnoQy0YwdMLxPG7Dqo q7wUEnbsU5+qUys9UlBvhej7FvXAYlSvfLJ0WHxeOBcSc5DWe2fxd+oLrFMnJFWIgywlLSoXxBTRy /gMoA08LKwB/PDGh7bzvMfoPYIRYanE6hxjNqLo4LSkDSZYRttLV3OmsFK5ma4jIn0iGSm8p9cQpP LG3Zx0eyXecZWYe1/kP+TpeOXukNS52S8f64TrLsAZqJwWkW31XGIOl0+cjfT7Ch8FO8yV77I8yWf ykhdAImLVvVAWnuaGgtl5caXF0OnQ+0pDxln4tokk1dzJmu6rJuN/YRedDCXe7Rf0KzjAit4zYo9n Nq3AY6GXyBQYyQ==; In-Reply-To: <87ttbx73zu.fsf@> (message from =?iso-8859-1?Q?Bj=F6rn?= Bidar on Sun, 24 Nov 2024 04:35:49 +0200) 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:325651 Archived-At: > From: Björn Bidar > Cc: Ship Mints , yantar92@posteo.net, > emacs-devel@gnu.org > Date: Sun, 24 Nov 2024 04:35:49 +0200 > > Eli Zaretskii writes: > > >> From: Ship Mints > >> Date: Fri, 22 Nov 2024 12:47:22 -0500 > >> Cc: Alan Mackenzie , emacs-devel@gnu.org > >> > >> 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. > > > > Branches are "cheap" to create, but are "expensive" because too many > > active branches tend to increase the probability of mistakes when > > people push changes to the wrong branch or merge from/to the wrong > > branch. > > Rules on such branches should help for example for Glibc there are rules > for namespace specifically to avoid this kind of issue.[1] We already have two namespaces: 'feature' and 'scratch'. I don't think we need more, but significantly, even these two get people confused as to where to create branches in each case. You can see enough questions about that on the list to realize that this is a non-trivial burden. > These test branches exist to experiment, create commits such as fixup > commits that won't reflect the actual commits that would be merged after > the changes in said branch would be in a working state. That's not the issue here; for code that is not ready for mainline we already use branches. In the context of this discussion, branches were suggested as ways to install controversial changes. I don't see any significant advantages to that, only disadvantages. See below. > > Branches also make it a bit harder to track changes people install. > > It depends on how they are organized. Not for "tracking" I had in mind. I usually review all the changes that get installed into our Git repository, so that I could fix or flag or start discussion for any of them that didn't do a clean job or left some left-overs, or might be plain wrong. More branches means harder work for this purpose. > E.g. if topic branches are merged > into master which only contain extra commits related to that topic they > are easy to track. However if a topic branch contains merge commits > where they should have been rebased first before merging instead of > merging mater back then these can cause unnecessary noise in the commit > history. The latter is indeed what happens in most cases with long-lived feature branches. > > So I don't think I like this proposal for changing our procedures. > > Change is hard but without change issues will potentially keep existing. We know that, right? Which is why changes in this area must have advantages that outweigh the disadvantages. In this case, I don't see any significant advantages, but I do see disadvantages. One significant disadvantage is that changes on a branch don't get tried by too many people (how many of the people here are routinely building, let alone using, the two feature branches we have now?), so feedback is much harder to get and much slower to come in. For changes that might be controversial, this is from my POV a crucial disadvantage, because decision-making in those cases must have feedback. > Making use of features that different systems offer can help to relieve > some of the friction and make communication of changes easier. I don't believe the friction can be relieved by these measures, no. Branches in our Git repository are still considered "blessed" to a degree, and don't really cause people with high emotions to cool down. We had enough examples of that, so this is not theory, it's fact. Branches for this purpose is a form of procrastination, and won't help making the decision or relive the friction. > It would be best to take the things learned by people outside of the > personal bubble into account. Often they can show use things that we > have become blind to or would have never thought of in the first place. Indeed. Which is why we do that all the time; the fact that there are 3 co-maintainers, each one with his specific experience and views, and we consult among us when controversial issues arise before taking actions, should tell you that at least the things learned by us, directly and indirectly, are brought to bear in these situations.