From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Question about intended behavior of 'insert-for-yank-1'. Date: Tue, 04 Oct 2016 12:40:49 -0500 Message-ID: <87fuocnhb2.fsf@red-bean.com> References: <874m5lr92d.fsf@red-bean.com> <83eg4p9hqk.fsf@gnu.org> <87inu1ghud.fsf@red-bean.com> <83y42x7yud.fsf@gnu.org> <87poo8g2zi.fsf@red-bean.com> <7abf7a00-3f17-4ef6-bfbd-0f5df4e7acd6@default> <87twcutfqe.fsf@red-bean.com> <83twcuorrq.fsf@gnu.org> <87oa31qm22.fsf@red-bean.com> <83shscodl1.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1475602877 593 195.159.176.226 (4 Oct 2016 17:41:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2016 17:41:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: drew.adams@oracle.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 04 19:41:12 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brTiD-00074w-Iw for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 19:41:05 +0200 Original-Received: from localhost ([::1]:44521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brTiB-0002HH-Vi for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 13:41:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brTi5-0002HA-O9 for emacs-devel@gnu.org; Tue, 04 Oct 2016 13:40:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brThz-0005SC-L6 for emacs-devel@gnu.org; Tue, 04 Oct 2016 13:40:56 -0400 Original-Received: from mail-it0-x230.google.com ([2607:f8b0:4001:c0b::230]:38512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brThz-0005Ry-GI; Tue, 04 Oct 2016 13:40:51 -0400 Original-Received: by mail-it0-x230.google.com with SMTP id o19so135078271ito.1; Tue, 04 Oct 2016 10:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=OmyTYhjUMHUgD3tEVhH8Wb9Pdju0ekIablW/h1lUd/A=; b=Zf61/CCIZkuw849ygEGEdmXnPmz1byeTlBuNr/HX+EiQ+UzULTm6tIagoS1QkDeqM3 nV6x2nnSbd9fWawl6sZeHEcl54QXqqylNGAg4VeXTTdMv8Fx04BncZChAUIq5zrY6map mzPD3Xc5nVt34ITQWsIve0tEPqqAonYxCB7SXhqaFOs283gzNRrY4qQHzX+Bvj2xQdDF qi95qeR4bavck1yaBr4AZDoLI+WN2Ydlu4BhWSO4qj6mL/p+z5s47bea+CKIolAcD2Hm eUA9gIzgrLhu6TuzTlskaM8p6GOGM/3h++YuN9+0QnjhX9SMMN5Xr9tLFUx2yxMCXH8e ppww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=OmyTYhjUMHUgD3tEVhH8Wb9Pdju0ekIablW/h1lUd/A=; b=ZBYiMGQ93EGZSkeluzOrTlQ/0d1HdWTZ9jC2VHMUWEo+IgKAurj6NMUxrUMrcH4E3N wBi1YKqocnzVgYEGHIlYWbWFEvMb6VFRJIzb504hVobbg5rgkGUUROM4T4HvbMIW0xeF yGwuFl/VT593n5FmO56Pm/CSHoQia2ESqxry5go8a6nF72B/uUeY3m4SV5TXh7zAkbTe ILp6KXav/cYflrDfu5CKH6nz+iKfEBpprCdIKpikC3pepsdfMEIKu44KAQNlWaVs5UgU 9bV5tdwBBk3jFjTOD4n8oQNowxe6SyoXiox2XJ01KQ2NIHvE16+jfdw9+4kKQ9FqUVMF cWEQ== X-Gm-Message-State: AA6/9RlI7w/bjpsyrVJNbzqOoRyqqjP548W+8rI9C4m8rAiK6nz/n5DXlKk3RdQah5fs9Q== X-Received: by 10.36.193.130 with SMTP id e124mr23647445itg.53.1475602850686; Tue, 04 Oct 2016 10:40:50 -0700 (PDT) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id c36sm2013346itd.2.2016.10.04.10.40.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Oct 2016 10:40:49 -0700 (PDT) In-Reply-To: <83shscodl1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Oct 2016 09:03:38 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c0b::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207983 Archived-At: Eli Zaretskii writes: >> The "Branches" section in CONTRIBUTE makes a distinction between >> "development" and "bug fixes". I think of this change as more of a >> background improvement -- of the sort that just needs to get into >> Emacs eventually -- than as a bug fix of the sort meant by >> CONTRIBUTE. However, your mail implies that CONTRIBUTE means to >> include this sort of thing in the category "bug fix" too. You >> probably have a better handle on the intentions behind the language >> in CONTRIBUTE than I do, so I'll re-interpret that section >> accordingly. > >You need to understand the logic behind the instructions in >CONTRIBUTE: the release branch should only get fixes that are either >necessary, or are safe, i.e. cannot possibly break the release. And >doc changes obviously belong to this latter class. I understand that logic. However, do you mean s/only/always/ above? The question is whether it is wrong to commit it to master instead, not whether it would have been right to commit it to emacs-25. A non-urgent doc fix that lands on master will eventually "get into Emacs", when new release lines are created. This was good enough for me. You seem to be saying that, once the safe doc fix is available, it should always be committed to the current release branch. For the committer, this would add the mental overhead of figuring out whether or not a particular release branch is in a freeze state or not. This is actually non-trivial to figure out, since it's not maintained as a visible flag in some designated place, but rather as a thread on the mailing list, which I then have to go search for. So for non-urgent stuff like this, I find it easier to just commit to master, because then I don't have to worry about the state of the current release branch. I can start worrying about it, if you think it's important. I just wanted to clarify why I aimed this change at master, and to see if my explanation affects the course of action you recommend for situations like this. (When I want a fix to go into the current release, then I expend the extra effort to determine whether I can put it on the release branch.) Now, *maybe* it is the case that a super-safe change like this is allowed onto a release branch even when that branch is frozen. But I don't know that for sure, and CONTRIBUTE doesn't say. Maybe this is just a doc bug in CONTRIBUTE and we should fix it. IOW, committing to master wasn't an accident; it resulted from a balancing of priorities. >I added a sentence about doc fixes to CONTRIBUTE. That will help either way. Thank you. Best regards, -Karl