all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: drew.adams@oracle.com, emacs-devel@gnu.org
Subject: Re: Question about intended behavior of 'insert-for-yank-1'.
Date: Tue, 04 Oct 2016 12:40:49 -0500	[thread overview]
Message-ID: <87fuocnhb2.fsf@red-bean.com> (raw)
In-Reply-To: <83shscodl1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Oct 2016 09:03:38 +0300")

Eli Zaretskii <eliz@gnu.org> 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



  reply	other threads:[~2016-10-04 17:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12  5:17 Question about intended behavior of 'insert-for-yank-1' Karl Fogel
2016-09-12 16:59 ` Eli Zaretskii
2016-09-12 17:15   ` Karl Fogel
2016-09-12 18:32     ` Eli Zaretskii
2016-09-12 22:36       ` Karl Fogel
2016-09-12 22:54         ` Drew Adams
2016-09-12 23:08           ` Karl Fogel
2016-10-03  0:53           ` Karl Fogel
2016-10-03  3:17             ` Noam Postavsky
2016-10-03  6:53               ` Eli Zaretskii
2016-10-03 19:21               ` Karl Fogel
2016-10-03  6:44             ` Eli Zaretskii
2016-10-03 19:17               ` Karl Fogel
2016-10-04  6:03                 ` Eli Zaretskii
2016-10-04 17:40                   ` Karl Fogel [this message]
2016-10-04 18:19                     ` Eli Zaretskii
2016-10-04 20:16                       ` Davis Herring
2016-10-04 21:04                       ` Karl Fogel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fuocnhb2.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.