bug#34776: 27.0.50; Some questions about choose-completion-string-functions

bug#34776: 27.0.50; Some questions about choose-completion-string-functions

[Eric Abrahamsen]

I'm trying to use `choose-completion-string-functions' to do some
"stuff" after the user finishes a completion, and have two questions:

1. The docstring of this variable says it is called with three
   arguments, but in fact it's called with four: the fourth is passed as
   nil, and is only there for backward compatibility, apparently. But
   still, you can't use a function that only accepts three args. I can
   provide a patch for the docstring if this is correct.
2. The code in `choose-completion-string' behaves as though the above
   variable is buffer local, but it is never declared to be so. I'm not
   sure if this is a bug (ie, we should be using `defvar-local'), or
   whether I should be adding functions here using the (local 'SYMBOL)
   convention of `add-function'. If that's the case, that's probably
   also a docstring bug, as we should warn users that they'll want to
   specify a local variable.

WDYT?

Eric

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Actually it looks like I was wrong about using add-function with
choose-completion-string-functions, it's just a plain list you stick
functions into. I think it has to be an error not to declare it
buffer-local... I've worked around this with `make-local-variable', but
I'm halfway sure this should be a defvar-local...?

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Glenn Morris]

Eric Abrahamsen wrote:

> Actually it looks like I was wrong about using add-function with
> choose-completion-string-functions, it's just a plain list you stick
> functions into. I think it has to be an error not to declare it
> buffer-local... I've worked around this with `make-local-variable', but
> I'm halfway sure this should be a defvar-local...?

The two uses in the Emacs code-base use add-hook without LOCAL.
completing-read-multiple and ido-common-initialization.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]


On 03/08/19 21:07 PM, Glenn Morris wrote:
> Eric Abrahamsen wrote:
>
>> Actually it looks like I was wrong about using add-function with
>> choose-completion-string-functions, it's just a plain list you stick
>> functions into. I think it has to be an error not to declare it
>> buffer-local... I've worked around this with `make-local-variable', but
>> I'm halfway sure this should be a defvar-local...?
>
> The two uses in the Emacs code-base use add-hook without LOCAL.
> completing-read-multiple and ido-common-initialization.

You're right, I was misinterpreting the code and comments as saying the
functions should be buffer local, when it just meant they *could* be
buffer local. I'll use add-hook with LOCAL.

So never mind! But I'd still like to add something like the attached, as
functions following the current docstring will raise an error.

Eric


[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 589 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index d4ae5ebb1f..0274bdb459 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8188,6 +8188,9 @@ choose-completion-string-functions
 BUFFER - the buffer in which the choice should be inserted,
 BASE-POSITION - where to insert the completion.
 
+Functions should also accept and ignore a potential fourth
+argument, passed for backwards compatibility.
+
 If a function in the list returns non-nil, that function is supposed
 to have inserted the CHOICE in the BUFFER, and possibly exited
 the minibuffer; no further functions will be called.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Noam Postavsky]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> So never mind! But I'd still like to add something like the attached, as
> functions following the current docstring will raise an error.
>
> Eric
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index d4ae5ebb1f..0274bdb459 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8188,6 +8188,9 @@ choose-completion-string-functions
>  BUFFER - the buffer in which the choice should be inserted,
>  BASE-POSITION - where to insert the completion.
>  
> +Functions should also accept and ignore a potential fourth
> +argument, passed for backwards compatibility.
> +

Looks good to me.  And it can go to emacs-26 since it's a doc fix.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Noam Postavsky <npostavs@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> So never mind! But I'd still like to add something like the attached, as
>> functions following the current docstring will raise an error.
>>
>> Eric
>>
>> diff --git a/lisp/simple.el b/lisp/simple.el
>> index d4ae5ebb1f..0274bdb459 100644
>> --- a/lisp/simple.el
>> +++ b/lisp/simple.el
>> @@ -8188,6 +8188,9 @@ choose-completion-string-functions
>>  BUFFER - the buffer in which the choice should be inserted,
>>  BASE-POSITION - where to insert the completion.
>>  
>> +Functions should also accept and ignore a potential fourth
>> +argument, passed for backwards compatibility.
>> +
>
> Looks good to me.  And it can go to emacs-26 since it's a doc fix.

Done, thanks.

Welcome back!

E

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Glenn Morris]

> And it can go to emacs-26 since it's a doc fix.

The RC said Emacs 26.2 was to be released March 27...
Part of making a release is for people to stop changing that branch.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eli Zaretskii]

On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org> wrote:
> 
> > And it can go to emacs-26 since it's a doc fix.
> 
> The RC said Emacs 26.2 was to be released March 27...
> Part of making a release is for people to stop changing that branch.

Unfortunately, that ship has sailed, since within an hour of RC release a new commit was pushed to the release branch, and another one a week later, without asking.  So now the RC tarball will not be able to be renamed anyway, and the rationale for withholding doc changes is null and void.

"Best laid plans" and all that.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

> On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org> wrote:
>> 
>> > And it can go to emacs-26 since it's a doc fix.
>> 
>> The RC said Emacs 26.2 was to be released March 27...
>> Part of making a release is for people to stop changing that branch.
>
> Unfortunately, that ship has sailed, since within an hour of RC
> release a new commit was pushed to the release branch, and another one
> a week later, without asking. So now the RC tarball will not be able
> to be renamed anyway, and the rationale for withholding doc changes is
> null and void.
>
> "Best laid plans" and all that.

This sounds like a job for a git hook. I pay fairly close attention to
emacs.devel for someone who isn't an Emacs dev, and apparently I missed
this billboard.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eli Zaretskii]

On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org>
> wrote:
> >> 
> >> > And it can go to emacs-26 since it's a doc fix.
> >> 
> >> The RC said Emacs 26.2 was to be released March 27...
> >> Part of making a release is for people to stop changing that
> branch.
> >
> > Unfortunately, that ship has sailed, since within an hour of RC
> > release a new commit was pushed to the release branch, and another
> one
> > a week later, without asking. So now the RC tarball will not be able
> > to be renamed anyway, and the rationale for withholding doc changes
> is
> > null and void.
> >
> > "Best laid plans" and all that.
> 
> This sounds like a job for a git hook. I pay fairly close attention to
> emacs.devel for someone who isn't an Emacs dev, and apparently I
> missed
> this billboard.

Not sure which billboard jou think you missed, but in general, I don't see here any problem for which a commit hook would be a good solution.  The existing hooks are already annoying enough, and are too easy to bypass to be reliable.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org>
>> wrote:
>> >> 
>> >> > And it can go to emacs-26 since it's a doc fix.
>> >> 
>> >> The RC said Emacs 26.2 was to be released March 27...
>> >> Part of making a release is for people to stop changing that
>> branch.
>> >
>> > Unfortunately, that ship has sailed, since within an hour of RC
>> > release a new commit was pushed to the release branch, and another
>> one
>> > a week later, without asking. So now the RC tarball will not be able
>> > to be renamed anyway, and the rationale for withholding doc changes
>> is
>> > null and void.
>> >
>> > "Best laid plans" and all that.
>> 
>> This sounds like a job for a git hook. I pay fairly close attention to
>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>> missed
>> this billboard.
>
> Not sure which billboard jou think you missed, but in general, I don't
> see here any problem for which a commit hook would be a good solution.
> The existing hooks are already annoying enough, and are too easy to
> bypass to be reliable.

What I meant was: if 200 people have the ability to push to the repo,
but 50 of them aren't checking the mailing lists regularly, then you
call a halt to an RC, that's 50 people who don't know they shouldn't
push. It seems like a lot more work to chase after those 50 than to
close the gate and reject pushes to that particular release.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org>
>>> wrote:
>>> >>
>>> >> > And it can go to emacs-26 since it's a doc fix.
>>> >>
>>> >> The RC said Emacs 26.2 was to be released March 27...
>>> >> Part of making a release is for people to stop changing that
>>> branch.
>>> >
>>> > Unfortunately, that ship has sailed, since within an hour of RC
>>> > release a new commit was pushed to the release branch, and another
>>> one
>>> > a week later, without asking. So now the RC tarball will not be able
>>> > to be renamed anyway, and the rationale for withholding doc changes
>>> is
>>> > null and void.
>>> >
>>> > "Best laid plans" and all that.
>>>
>>> This sounds like a job for a git hook. I pay fairly close attention to
>>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>>> missed
>>> this billboard.
>>
>> Not sure which billboard jou think you missed, but in general, I don't
>> see here any problem for which a commit hook would be a good solution.
>> The existing hooks are already annoying enough, and are too easy to
>> bypass to be reliable.
>
> What I meant was: if 200 people have the ability to push to the repo,
> but 50 of them aren't checking the mailing lists regularly, then you
> call a halt to an RC, that's 50 people who don't know they shouldn't
> push. It seems like a lot more work to chase after those 50 than to
> close the gate and reject pushes to that particular release.

I keep hitting C-c C-s (message-send) instead of C-x C-s (which would
save a draft), which I hope will explain my slightly rude tone here.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eli Zaretskii]

On April 10, 2019 10:22:14 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris
> <rgm@gnu.org>
> >> wrote:
> >> >> 
> >> >> > And it can go to emacs-26 since it's a doc fix.
> >> >> 
> >> >> The RC said Emacs 26.2 was to be released March 27...
> >> >> Part of making a release is for people to stop changing that
> >> branch.
> >> >
> >> > Unfortunately, that ship has sailed, since within an hour of RC
> >> > release a new commit was pushed to the release branch, and
> another
> >> one
> >> > a week later, without asking. So now the RC tarball will not be
> able
> >> > to be renamed anyway, and the rationale for withholding doc
> changes
> >> is
> >> > null and void.
> >> >
> >> > "Best laid plans" and all that.
> >> 
> >> This sounds like a job for a git hook. I pay fairly close attention
> to
> >> emacs.devel for someone who isn't an Emacs dev, and apparently I
> >> missed
> >> this billboard.
> >
> > Not sure which billboard jou think you missed, but in general, I
> don't
> > see here any problem for which a commit hook would be a good
> solution.
> > The existing hooks are already annoying enough, and are too easy to
> > bypass to be reliable.
> 
> What I meant was: if 200 people have the ability to push to the repo,
> but 50 of them aren't checking the mailing lists regularly, then you
> call a halt to an RC, that's 50 people who don't know they shouldn't
> push. It seems like a lot more work to chase after those 50 than to
> close the gate and reject pushes to that particular release.

There's no need to check the mailing list, this stuff is in CONTRIBUTE.  That's why I never called for any halts.

Branch freezing for release (WAS: bug#34776)

[Noam Postavsky]

>>>>>> The RC said Emacs 26.2 was to be released March 27...  Part of
>>>>>> making a release is for people to stop changing that branch.
>>>>>
>>>>> Unfortunately, that ship has sailed, since within an hour of RC
>>>>> release a new commit was pushed to the release branch [...]

>>>> This sounds like a job for a git hook. I pay fairly close
>>>> attention to emacs.devel for someone who isn't an Emacs dev, and
>>>> apparently I missed this billboard.
>>>
>>> Not sure which billboard jou think you missed, but in general, I
>>> don't see here any problem for which a commit hook would be a good
>>> solution.  The existing hooks are already annoying enough, and are
>>> too easy to bypass to be reliable.

Git supports server-side hooks which can't be bypassed.  If I read
githooks(5) correctly, then putting an update hook on the server with
contents:

    if [ "$1" = emacs-26 ]; then
       echo "Branch $1 is frozen"
       exit 1
    fi

would do it.  There would still be some additional complication with
letting in the commit for the RC itself though.  Andreas' suggestion to
just let unexpected commits miss being in the release seems simpler.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34776#61

>> What I meant was: if 200 people have the ability to push to the repo,
>> but 50 of them aren't checking the mailing lists regularly, then you
>> call a halt to an RC, that's 50 people who don't know they shouldn't
>> push. It seems like a lot more work to chase after those 50 than to
>> close the gate and reject pushes to that particular release.
>
> There's no need to check the mailing list, this stuff is in
> CONTRIBUTE.  That's why I never called for any halts.

CONTRIBUTE says:

    Doc fixes are always considered "safe" -- even when a release branch is
    in feature freeze, it can still receive doc fixes.

I don't see anything there about not pushing after an RC is made (and
how would someone know about the RC without checking the mailing list?)

Re: Branch freezing for release (WAS: bug#34776)

[Eli Zaretskii]

On April 10, 2019 11:57:09 AM GMT+03:00, Noam Postavsky <npostavs@gmail.com> wrote:
> >>>>>> The RC said Emacs 26.2 was to be released March 27...  Part of
> >>>>>> making a release is for people to stop changing that branch.
> >>>>>
> >>>>> Unfortunately, that ship has sailed, since within an hour of RC
> >>>>> release a new commit was pushed to the release branch [...]
> 
> >>>> This sounds like a job for a git hook. I pay fairly close
> >>>> attention to emacs.devel for someone who isn't an Emacs dev, and
> >>>> apparently I missed this billboard.
> >>>
> >>> Not sure which billboard jou think you missed, but in general, I
> >>> don't see here any problem for which a commit hook would be a good
> >>> solution.  The existing hooks are already annoying enough, and are
> >>> too easy to bypass to be reliable.
> 
> Git supports server-side hooks which can't be bypassed.  If I read
> githooks(5) correctly, then putting an update hook on the server with
> contents:
> 
>     if [ "$1" = emacs-26 ]; then
>        echo "Branch $1 is frozen"
>        exit 1
>     fi
> 
> would do it.  There would still be some additional complication with
> letting in the commit for the RC itself though.  Andreas' suggestion
> to
> just let unexpected commits miss being in the release seems simpler.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34776#61

We don't have access to the server, so doing this would be a significant complication, even if we ignore the annoyance of a rejected commit and a potential for failing to push if one doesn't watch the messages closely enough (actually happened to me at least once).

> >> What I meant was: if 200 people have the ability to push to the
> repo,
> >> but 50 of them aren't checking the mailing lists regularly, then
> you
> >> call a halt to an RC, that's 50 people who don't know they
> shouldn't
> >> push. It seems like a lot more work to chase after those 50 than to
> >> close the gate and reject pushes to that particular release.
> >
> > There's no need to check the mailing list, this stuff is in
> > CONTRIBUTE.  That's why I never called for any halts.
> 
> CONTRIBUTE says:
> 
> Doc fixes are always considered "safe" -- even when a release branch
> is
>     in feature freeze, it can still receive doc fixes.
> 
> I don't see anything there about not pushing after an RC is made (and
> how would someone know about the RC without checking the mailing
> list?)

There's no need to say anything else, since an RC should be tarred after all its changes are pushed and tagged.  That didn't happen this time by omission.  We all make mistakes at times.

Re: Branch freezing for release (WAS: bug#34776)

[Noam Postavsky]

On Wed, 10 Apr 2019 at 05:21, Eli Zaretskii <eliz@gnu.org> wrote:

> > >>>>>> The RC said Emacs 26.2 was to be released March 27...  Part of
> > >>>>>> making a release is for people to stop changing that branch.
> > >>>>>
> > >>>>> Unfortunately, that ship has sailed, since within an hour of RC
> > >>>>> release a new commit was pushed to the release branch [...]

> > CONTRIBUTE says:
> >
> > Doc fixes are always considered "safe" -- even when a release branch
> > is in feature freeze, it can still receive doc fixes.
> >
> > I don't see anything there about not pushing after an RC is made

> There's no need to say anything else, since an RC should be tarred after all its changes are pushed and tagged.  That didn't happen this time by omission.  We all make mistakes at times.

Ah, I had initially thought you meant the unfortunate mistake was on
part of the person/people pushing to emacs-26 after the RC. Makes more
sense this way.

Re: Branch freezing for release (WAS: bug#34776)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 10 Apr 2019 12:16:35 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>, Eric Abrahamsen <eric@ericabrahamsen.net>
> 
> > > I don't see anything there about not pushing after an RC is made
> 
> > There's no need to say anything else, since an RC should be tarred after all its changes are pushed and tagged.  That didn't happen this time by omission.  We all make mistakes at times.
> 
> Ah, I had initially thought you meant the unfortunate mistake was on
> part of the person/people pushing to emacs-26 after the RC.

If just one of these two things happened -- either they asked whether
it was okay to push, or the RC was pushed and tagged -- we'd be okay,
but none of them happened.

Re: Branch freezing for release

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Date: Wed, 10 Apr 2019 12:16:35 -0400
>> Cc: Emacs developers <emacs-devel@gnu.org>, Eric Abrahamsen <eric@ericabrahamsen.net>
>> 
>> > > I don't see anything there about not pushing after an RC is made
>> 
>> > There's no need to say anything else, since an RC should be tarred after all
>> > its changes are pushed and tagged. That didn't happen this time by omission.
>> > We all make mistakes at times.
>> 
>> Ah, I had initially thought you meant the unfortunate mistake was on
>> part of the person/people pushing to emacs-26 after the RC.
>
> If just one of these two things happened -- either they asked whether
> it was okay to push, or the RC was pushed and tagged -- we'd be okay,
> but none of them happened.

Just to be clear: is it okay to push/backport fixes to emacs-26 again?
I've noted the following commits as candidates for backporting:

[1: 10cd65878c]: Update documentation for indent-relative functions
  2019-04-05 19:48:21 -0500
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=10cd65878c741d2a22a1f2c36c54fcad4e516f72

[2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
  2019-04-03 17:55:40 +0100
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1

[3: 690c678fb6]: Fix comment-empty-lines docstring (bug#35152)
  2019-04-04 23:41:02 +0100
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=690c678fb6c1fb5b2f828f9bb90782bd0b01c399

N.B.: Commit [2] also includes small code changes, not just docfixes.

Thanks,

-- 
Basil

Re: Branch freezing for release

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Noam Postavsky <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
> Date: Wed, 10 Apr 2019 17:59:14 +0100
> 
> Just to be clear: is it okay to push/backport fixes to emacs-26 again?

Nothing's changed, the status is still according to CONTRIBUTE: the
next release is 26.2, i.e. the minor version is > 1, so only doc fixes
are automatically safe; the rest should get an explicit permission,
and generally they won't get it (since we already had RC1).

> I've noted the following commits as candidates for backporting:
> 
> [1: 10cd65878c]: Update documentation for indent-relative functions
>   2019-04-05 19:48:21 -0500
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=10cd65878c741d2a22a1f2c36c54fcad4e516f72
> 
> [2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
>   2019-04-03 17:55:40 +0100
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1
> 
> [3: 690c678fb6]: Fix comment-empty-lines docstring (bug#35152)
>   2019-04-04 23:41:02 +0100
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=690c678fb6c1fb5b2f828f9bb90782bd0b01c399
> 
> N.B.: Commit [2] also includes small code changes, not just docfixes.

I hope you now know the answer; if not, please ask for clarifications.

Re: Branch freezing for release

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Noam Postavsky <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
>> Date: Wed, 10 Apr 2019 17:59:14 +0100
>> 
>> Just to be clear: is it okay to push/backport fixes to emacs-26 again?
>
> Nothing's changed, the status is still according to CONTRIBUTE: the
> next release is 26.2, i.e. the minor version is > 1, so only doc fixes
> are automatically safe; the rest should get an explicit permission,
> and generally they won't get it (since we already had RC1).
>
>> I've noted the following commits as candidates for backporting:
>> 
>> [1: 10cd65878c]: Update documentation for indent-relative functions
>>   2019-04-05 19:48:21 -0500
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=10cd65878c741d2a22a1f2c36c54fcad4e516f72
>> 
>> [2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
>>   2019-04-03 17:55:40 +0100
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1
>> 
>> [3: 690c678fb6]: Fix comment-empty-lines docstring (bug#35152)
>>   2019-04-04 23:41:02 +0100
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=690c678fb6c1fb5b2f828f9bb90782bd0b01c399
>> 
>> N.B.: Commit [2] also includes small code changes, not just docfixes.
>
> I hope you now know the answer; if not, please ask for clarifications.

My understanding is that commits [1] and [3] above are automatically
safe and I may backport them, and that backporting commit [2] is
unlikely to receive your blessing.

But I would like to ask for it nonetheless, since commit [2] is an
obvious fix™ for a regression in 26.1:

[4: a9973a3c16]: Extend 'indent-relative' when its arg is non-nil
  2016-11-18 11:02:55 +0200
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9973a3c164060bde08a717b46023a3bf68909c8

I do, of course, understand I may have missed that ship.

Thanks for clarifying,

-- 
Basil

Re: Branch freezing for release

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
> Date: Wed, 10 Apr 2019 18:39:24 +0100
> 
> >> [1: 10cd65878c]: Update documentation for indent-relative functions
> >>   2019-04-05 19:48:21 -0500
> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=10cd65878c741d2a22a1f2c36c54fcad4e516f72
> >> 
> >> [2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
> >>   2019-04-03 17:55:40 +0100
> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1
> >> 
> >> [3: 690c678fb6]: Fix comment-empty-lines docstring (bug#35152)
> >>   2019-04-04 23:41:02 +0100
> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=690c678fb6c1fb5b2f828f9bb90782bd0b01c399
> >> 
> >> N.B.: Commit [2] also includes small code changes, not just docfixes.
> >
> > I hope you now know the answer; if not, please ask for clarifications.
> 
> My understanding is that commits [1] and [3] above are automatically
> safe and I may backport them, and that backporting commit [2] is
> unlikely to receive your blessing.

Yes, correct.

> But I would like to ask for it nonetheless, since commit [2] is an
> obvious fix™ for a regression in 26.1:
> 
> [4: a9973a3c16]: Extend 'indent-relative' when its arg is non-nil
>   2016-11-18 11:02:55 +0200
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9973a3c164060bde08a717b46023a3bf68909c8

The regression doesn't look serious enough to warrant a change at this
late stage.  We can talk about it again after Emacs 26.2 is out.

Thanks.

Re: Branch freezing for release

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
>> Date: Wed, 10 Apr 2019 18:39:24 +0100
>> 
>> >> [1: 10cd65878c]: Update documentation for indent-relative functions
>> >>   2019-04-05 19:48:21 -0500
>> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=10cd65878c741d2a22a1f2c36c54fcad4e516f72
>> >> 
>> >> [2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
>> >>   2019-04-03 17:55:40 +0100
>> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1
>> >> 
>> >> [3: 690c678fb6]: Fix comment-empty-lines docstring (bug#35152)
>> >>   2019-04-04 23:41:02 +0100
>> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=690c678fb6c1fb5b2f828f9bb90782bd0b01c399
>> >> 
>> >> N.B.: Commit [2] also includes small code changes, not just docfixes.
>> >
>> > I hope you now know the answer; if not, please ask for clarifications.
>> 
>> My understanding is that commits [1] and [3] above are automatically
>> safe and I may backport them, and that backporting commit [2] is
>> unlikely to receive your blessing.
>
> Yes, correct.

Thanks, I backported those two earlier today.

>> But I would like to ask for it nonetheless, since commit [2] is an
>> obvious fix™ for a regression in 26.1:
>> 
>> [4: a9973a3c16]: Extend 'indent-relative' when its arg is non-nil
>>   2016-11-18 11:02:55 +0200
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9973a3c164060bde08a717b46023a3bf68909c8
>
> The regression doesn't look serious enough to warrant a change at this
> late stage.  We can talk about it again after Emacs 26.2 is out.

Wilco.

-- 
Basil

Re: Branch freezing for release

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
>> Date: Wed, 10 Apr 2019 18:39:24 +0100
>> 
>> >> [2: 0e468a6204]: Avoid using obsolete indent-relative-maybe
>> >>   2019-04-03 17:55:40 +0100
>> >>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e468a620458fecd003c396050aa6deb722982c1
>> >> 
>> >> N.B.: Commit [2] also includes small code changes, not just docfixes.
>> 
>> My understanding is that commits [1] and [3] above are automatically
>> safe and I may backport them, and that backporting commit [2] is
>> unlikely to receive your blessing.
>
> Yes, correct.
>
>> But I would like to ask for it nonetheless, since commit [2] is an
>> obvious fix™ for a regression in 26.1:
>> 
>> [4: a9973a3c16]: Extend 'indent-relative' when its arg is non-nil
>>   2016-11-18 11:02:55 +0200
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9973a3c164060bde08a717b46023a3bf68909c8
>
> The regression doesn't look serious enough to warrant a change at this
> late stage.  We can talk about it again after Emacs 26.2 is out.

Is it OK to backport commit [2] above to emacs-26 now?

Thanks,

-- 
Basil

Re: Branch freezing for release

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
> Date: Mon, 22 Apr 2019 14:03:46 +0100
> 
> Is it OK to backport commit [2] above to emacs-26 now?

Yes, thanks.

Re: Branch freezing for release

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: <npostavs@gmail.com>,  <eric@ericabrahamsen.net>,  <emacs-devel@gnu.org>
>> Date: Mon, 22 Apr 2019 14:03:46 +0100
>> 
>> Is it OK to backport commit [2] above to emacs-26 now?
>
> Yes, thanks.

Thanks, done:

[1: 7565d2d2fb]: Backport: Avoid using obsolete indent-relative-maybe
  2019-04-22 16:13:46 +0100
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7565d2d2fbc8eec314d40e2e99992c8864307e1b

-- 
Basil

Re: Branch freezing for release

[Stefan Monnier]

> Nothing's changed, the status is still according to CONTRIBUTE: the
> next release is 26.2, i.e. the minor version is > 1, so only doc fixes
> are automatically safe; the rest should get an explicit permission,
> and generally they won't get it (since we already had RC1).

What about bug-fixes for 26.3?


        Stefan

Re: Branch freezing for release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Apr 2019 13:56:06 -0400
> 
> > Nothing's changed, the status is still according to CONTRIBUTE: the
> > next release is 26.2, i.e. the minor version is > 1, so only doc fixes
> > are automatically safe; the rest should get an explicit permission,
> > and generally they won't get it (since we already had RC1).
> 
> What about bug-fixes for 26.3?

We can talk about that once Emacs 26.2 is out.

Re: Branch freezing for release

[Stefan Monnier]

>> What about bug-fixes for 26.3?
> We can talk about that once Emacs 26.2 is out.

That was exactly my point: you need to follow emacs-devel to know what
can go to emacs-26.


        Stefan

Re: Branch freezing for release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Apr 2019 14:54:13 -0400
> 
> >> What about bug-fixes for 26.3?
> > We can talk about that once Emacs 26.2 is out.
> 
> That was exactly my point: you need to follow emacs-devel to know what
> can go to emacs-26.

Only if you have interest in fixing something or backporting some fix.

And actually, there's no need to follow even then, just ask about
specific changes.

Re: Branch freezing for release

[Dmitry Gutov]

On 10.04.2019 22:19, Eli Zaretskii wrote:

>> That was exactly my point: you need to follow emacs-devel to know what
>> can go to emacs-26.
> 
> Only if you have interest in fixing something or backporting some fix.

But there are period where you can commit to an emacs-xx branch without 
asking in advance.

Re: Branch freezing for release

[Noam Postavsky]

On Wed, 10 Apr 2019 at 16:16, Dmitry Gutov <dgutov@yandex.ru> wrote:

> But there are period where you can commit to an emacs-xx branch without
> asking in advance.

Which, if I understand CONTRIBUTE correctly, is only when the emacs-xx
branch has the version set to xx.0.mm. Though perhaps there is some
fuzziness in CONTRIBUTE over the exact meaning of "is in the very last
stages of its pretest".

Re: Branch freezing for release

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 10 Apr 2019 20:12:00 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, 10 Apr 2019 at 16:16, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> > But there are period where you can commit to an emacs-xx branch without
> > asking in advance.
> 
> Which, if I understand CONTRIBUTE correctly, is only when the emacs-xx
> branch has the version set to xx.0.mm.

Yes, exactly.

> Though perhaps there is some fuzziness in CONTRIBUTE over the exact
> meaning of "is in the very last stages of its pretest".

If someone can suggest a better way of saying that, please do.  The
text does say soon afterwards "if you are unsure, ask".

Re: Branch freezing for release

[Noam Postavsky]

On Thu, 11 Apr 2019 at 09:53, Eli Zaretskii <eliz@gnu.org> wrote:

> > > But there are period where you can commit to an emacs-xx branch without
> > > asking in advance.
> >
> > Which, if I understand CONTRIBUTE correctly, is only when the emacs-xx
> > branch has the version set to xx.0.mm.
>
> Yes, exactly.
>
> > Though perhaps there is some fuzziness in CONTRIBUTE over the exact
> > meaning of "is in the very last stages of its pretest".
>
> If someone can suggest a better way of saying that, please do.  The
> text does say soon afterwards "if you are unsure, ask".

Maybe it helps to spell out a number?

--- i/CONTRIBUTE
+++ w/CONTRIBUTE
@@ -289,9 +289,8 @@ admin/notes/git-workflow.

 If you are fixing a bug that exists in the current release, you should
 generally commit it to the release branch; it will be merged to the
-master branch later by the gitmerge function.  However, when the
-release branch is for Emacs version NN.2 and later, or when it is for
-Emacs version NN.1 that is in the very last stages of its pretest,
+master branch later by the gitmerge function.  However, unless the
+release branch is on Emacs version NN.0.90 or lower,
 that branch is considered to be in a feature freeze: only bug fixes
 that are "safe" or are fixing major problems should go to the release
 branch, the rest should be committed to the master branch.  This is so

Re: Branch freezing for release

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 11 Apr 2019 21:03:28 -0400
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > > Though perhaps there is some fuzziness in CONTRIBUTE over the exact
> > > meaning of "is in the very last stages of its pretest".
> >
> > If someone can suggest a better way of saying that, please do.  The
> > text does say soon afterwards "if you are unsure, ask".
> 
> Maybe it helps to spell out a number?

I'd hesitate to fix the number at 90 (or any other specific number),
because sometimes .90 is not close enough.  We could say .100, but
AFAIR that happened only once or twice in the history, so it would not
be helpful.  The problem here is that the number is not determined by
how close we think we are to the release, its correlation with that is
very weak.

Re: Branch freezing for release

[Noam Postavsky]

On Fri, 12 Apr 2019 at 03:04, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Noam Postavsky <npostavs@gmail.com>
> > Date: Thu, 11 Apr 2019 21:03:28 -0400
> > Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> > > > Though perhaps there is some fuzziness in CONTRIBUTE over the exact
> > > > meaning of "is in the very last stages of its pretest".
> > >
> > > If someone can suggest a better way of saying that, please do.  The
> > > text does say soon afterwards "if you are unsure, ask".
> >
> > Maybe it helps to spell out a number?
>
> I'd hesitate to fix the number at 90 (or any other specific number),
> because sometimes .90 is not close enough.  We could say .100, but
> AFAIR that happened only once or twice in the history, so it would not
> be helpful.  The problem here is that the number is not determined by
> how close we think we are to the release, its correlation with that is
> very weak.

Yes, the only way to know is to follow emacs-devel, so for someone who
doesn't follow the list, asking at anything above .90 is the only safe
recommendation, right?

Re: Branch freezing for release

[Stefan Monnier]

> Yes, the only way to know is to follow emacs-devel, so for someone who
> doesn't follow the list, asking at anything above .90 is the only safe
> recommendation, right?

What's so bad about using another branch once we're "close to the
release"? 


        Stefan

Re: Branch freezing for release

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Fri, 12 Apr 2019 06:18:33 -0400
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > I'd hesitate to fix the number at 90 (or any other specific number),
> > because sometimes .90 is not close enough.  We could say .100, but
> > AFAIR that happened only once or twice in the history, so it would not
> > be helpful.  The problem here is that the number is not determined by
> > how close we think we are to the release, its correlation with that is
> > very weak.
> 
> Yes, the only way to know is to follow emacs-devel, so for someone who
> doesn't follow the list, asking at anything above .90 is the only safe
> recommendation, right?

It's fine with me, but it would have meant that the emacs-26 branch
was frozen from the second pretest, which probably is too
conservative.  I don't remember when we last started pretest with a
number below 90, maybe only when Emacs 21 was in its pretest.  But if
others don't mind, neither do I.

Re: Branch freezing for release

[Dmitry Gutov]

On 12.04.2019 10:04, Eli Zaretskii wrote:

>>> If someone can suggest a better way of saying that, please do.  The
>>> text does say soon afterwards "if you are unsure, ask".
>>
>> Maybe it helps to spell out a number?
> 
> I'd hesitate to fix the number at 90 (or any other specific number),
> because sometimes .90 is not close enough.  We could say .100, but
> AFAIR that happened only once or twice in the history, so it would not
> be helpful.  The problem here is that the number is not determined by
> how close we think we are to the release, its correlation with that is
> very weak.

A bit arbitrary, but OK.

Instead, though, we could say something like: "you are allowed to commit 
to branches named emacs-xy basically anything except huge new features, 
but branches named emacs-xy.z are special, and you should only commit 
there if you know you can, and ask if you're unsure".

This kind of release branching should be familiar to many. I've read 
about it being used for Firefox, for example, several years ago.

Re: Branch freezing for release

[Stefan Monnier]

>>>>>>> The RC said Emacs 26.2 was to be released March 27...  Part of
>>>>>>> making a release is for people to stop changing that branch.
>>>>>> Unfortunately, that ship has sailed, since within an hour of RC
>>>>>> release a new commit was pushed to the release branch [...]

FWIW, that's part of the reason why I suggested that we make
a emacs-26.2 branch once we start entering the phase where we should not
push any change unless explicitly allowed by the maintainer.  This way
people can keep pushing random bug fixes to emacs-26, unaware that
an emacs-26.2 was created.

It's also useful for bug fixes which we'd want to have in a hypothetical
26.3, so they don't get lost in master.  It makes the rules simple:

- master:      always open for business.
- emacs-NN:    bug-fixes only (merged back to master every once in a while)
- emacs-NN.MM: never touch unless specifically authorized to do so.

Look ma!  No need to follow emacs-devel to know in which phase we are!


        Stefan

Re: Branch freezing for release

[Andreas Schwab]

On Apr 10 2019, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> It's also useful for bug fixes which we'd want to have in a hypothetical
> 26.3, so they don't get lost in master.  It makes the rules simple:
>
> - master:      always open for business.
> - emacs-NN:    bug-fixes only (merged back to master every once in a while)
> - emacs-NN.MM: never touch unless specifically authorized to do so.

That's actually what we have right now, except that the emacs-26.2
branch is not public.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Branch freezing for release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Apr 2019 09:14:06 -0400
> 
> FWIW, that's part of the reason why I suggested that we make
> a emacs-26.2 branch once we start entering the phase where we should not
> push any change unless explicitly allowed by the maintainer.  This way
> people can keep pushing random bug fixes to emacs-26, unaware that
> an emacs-26.2 was created.

Unless the hypothetical emacs-26.2 branch is local, why would people
be unaware of its creation?  Git happily announces its creation and
each of its updates on every fetch/pull.

> It's also useful for bug fixes which we'd want to have in a hypothetical
> 26.3, so they don't get lost in master.  It makes the rules simple:
> 
> - master:      always open for business.
> - emacs-NN:    bug-fixes only (merged back to master every once in a while)
> - emacs-NN.MM: never touch unless specifically authorized to do so.

I don't see this as a simplification, I see this as a complication:
one more branch to track, to describe in CONTRIBUTE, to educate people
about, to avoid mixing with others, etc.

> Look ma!  No need to follow emacs-devel to know in which phase we are!

There's no need to follow emacs-devel now, either.  The rules are laid
out in CONTRIBUTE, and once each RC will have its modifications pushed
and tagged, the problem which led to this particular bikeshedding
should not happen again.  IOW, this is a normal process of learning
how to release Emacs cleanly.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Andreas Schwab]

On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:

> Unfortunately, that ship has sailed, since within an hour of RC release a new commit was pushed to the release branch, and another one a week later, without asking.  So now the RC tarball will not be able to be renamed anyway, and the rationale for withholding doc changes is null and void.

Why not?  Just tag the last commit that is contained in the rc release.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eli Zaretskii]

On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Unfortunately, that ship has sailed, since within an hour of RC
> release a new commit was pushed to the release branch, and another one
> a week later, without asking.  So now the RC tarball will not be able
> to be renamed anyway, and the rationale for withholding doc changes is
> null and void.
> 
> Why not?  Just tag the last commit that is contained in the rc
> release.
> 
> Andreas.

The RC contains several uncommitted changes.  Hopefully won't happen in the future.

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Andreas Schwab]

On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:

> On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
>> On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > Unfortunately, that ship has sailed, since within an hour of RC
>> release a new commit was pushed to the release branch, and another one
>> a week later, without asking.  So now the RC tarball will not be able
>> to be renamed anyway, and the rationale for withholding doc changes is
>> null and void.
>> 
>> Why not?  Just tag the last commit that is contained in the rc
>> release.
>> 
>> Andreas.
>
> The RC contains several uncommitted changes.  Hopefully won't happen in the future.

That isn't a problem either.  They can be put on a local branch, into
which upstream is merged after the tag.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eli Zaretskii]

On April 10, 2019 11:39:55 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab
> <schwab@suse.de> wrote:
> >> On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
> >> 
> >> > Unfortunately, that ship has sailed, since within an hour of RC
> >> release a new commit was pushed to the release branch, and another
> one
> >> a week later, without asking.  So now the RC tarball will not be
> able
> >> to be renamed anyway, and the rationale for withholding doc changes
> is
> >> null and void.
> >> 
> >> Why not?  Just tag the last commit that is contained in the rc
> >> release.
> >> 
> >> Andreas.
> >
> > The RC contains several uncommitted changes.  Hopefully won't happen
> in the future.
> 
> That isn't a problem either.  They can be put on a local branch, into
> which upstream is merged after the tag.
> 
> Andreas.

I decided it wasn't worth the hassle of releasing 26.2 from a side branch.