From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about intended behavior of 'insert-for-yank-1'. Date: Tue, 04 Oct 2016 21:19:06 +0300 Message-ID: <837f9om0yt.fsf@gnu.org> 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> <87fuocnhb2.fsf@red-bean.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1475605228 4629 195.159.176.226 (4 Oct 2016 18:20:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2016 18:20:28 +0000 (UTC) Cc: drew.adams@oracle.com, emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 04 20:20:24 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 1brUJz-0007QR-QS for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 20:20:07 +0200 Original-Received: from localhost ([::1]:44666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brUJy-0000BK-A5 for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 14:20:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brUJN-0000B3-0Z for emacs-devel@gnu.org; Tue, 04 Oct 2016 14:19:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brUJI-0002Da-Kk for emacs-devel@gnu.org; Tue, 04 Oct 2016 14:19:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brUJI-0002DK-Gy; Tue, 04 Oct 2016 14:19:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3809 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1brUJE-0002MG-4G; Tue, 04 Oct 2016 14:19:22 -0400 In-reply-to: <87fuocnhb2.fsf@red-bean.com> (message from Karl Fogel on Tue, 04 Oct 2016 12:40:49 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:207984 Archived-At: > From: Karl Fogel > Cc: drew.adams@oracle.com, emacs-devel@gnu.org > Date: Tue, 04 Oct 2016 12:40:49 -0500 > > >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? I don't see the difference. "Only" means "always" in this case. > 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. It is "wrong" in the sense that committing to master will prevent the next release from having the fix, for no good reason, but committing to the release branch will never prevent master from having it. > 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. Doc fixes are always "urgent", in the sense that there's no reason to delay them. They can never do any harm. > You seem to be saying that, once the safe doc fix is available, it should always be committed to the current release branch. Yes. And not just "safe" doc fix: _any_ doc fix. Doc fixes are by definition safe. > 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. The freeze state is never relevant to doc fixes. It is only relevant to code changes. The purpose of a freeze is to prevent unsafe changes, and doc changes are never unsafe. > 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. If you have trouble with that, just ask before pushing. I think the decision is very simple, but if it isn't, John and myself are here to help. > 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. Once again, doc fixes are always "urgent". It may be easier for you to always commit to master, but that's not our process here, so it means someone else will have to watch your commits, detect problems like this, and then cherry-pick for you, or ask you to do that. It's a burden we'd like to avoid, and I think the rules are simple enough to allow anyone to follow them seamlessly. And if they are not simple enough, please just ask when in doubt. > I can start worrying about it, if you think it's important. It's important, yes. > (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.) No such considerations are necessary for documentation changes. the only reason not to commit a doc fix to the release branch is if the fix is relevant to behavior that's only available on master. > 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. Doc fixes are _always_ safe. > 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. CONTRIBUTE already does say that, I made the change there today. > IOW, committing to master wasn't an accident; it resulted from a balancing of priorities. I didn't think it was an accident, I just explained why your decision was incorrect. I understand that it was a good-faith mistake, so no sweat.