emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix bookmark-bmenu-list sorting.


From: Eli Zaretskii
Subject: Re: [PATCH] Fix bookmark-bmenu-list sorting.
Date: Fri, 04 Mar 2022 09:14:34 +0200

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: manuel@ledu-giraud.fr,  emacs-devel@gnu.org
> Date: Thu, 03 Mar 2022 21:13:04 -0600
> 
> >>  This looks correct to me.  Thank you for the fix.  I'm testing 
> >> it  now on 'emacs-28' and 'master' (it should behave the same 
> >> on both,  of course, but might as well make sure).  Assuming it 
> >> behaves as  expected, I'll apply using 'git patch' on the 
> >> emacs-28 branch. 
> > Please don't install new features on the release branch. 
>  
> This is a bugfix, not a new feature.

The original message didn't describe any bugs, so I concluded it was a
new feature.  Sorry about that.

However, if this is a bug, please tell:

  . what is the bug and how to reproduce it?
  . if this is a regression, what was the last Emacs version where the
    reproduction recipe worked correctly?

> I re-read the "Branches" section in CONTRIBUTE before I posted --
> the relevant part is this, I think:
> 
>   > 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, 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 to avoid destabilizing the next Emacs 
>   > release.
>   > If you are unsure whether your bug fix is "safe" enough for 
>   > the
>   > release branch, ask on the emacs-devel mailing list.
> 
> That indicates that 'emacs-28' is the right branch for this 
> change.  That branch is on version 28.0.91 right now, not 28.2 nor 
> late 28.1.

How do you know whether the current pretest of 28.1 is or isn't "in
the very latest stages of its pretest"?  The text says to ask if you
aren't sure.  As things are, we are, I hope, in the very latest
stages.

> I'm happy to put this change on whatever branch you prefer, of 
> course.

I will make up my mind after I know the answers to the above
questions.

> However, independent of this specific case, in general 
> how should one determine what branch to put something on, if the 
> guidance in CONTRIBUTE isn't enough?

It's a judgment call.  Which is why the text says to ask.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]