GNU bug report logs - #40990
Improve message-mode and isearch icons

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40990-done <at> debbugs.gnu.org
Subject: bug#40990: Improve message-mode and isearch icons
Date: Mon, 11 May 2020 17:18:15 +0300

On 11.05.2020 07:17, Eli Zaretskii wrote:
> On May 11, 2020 5:46:03 AM GMT+03:00, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> On 11.05.2020 05:35, Eli Zaretskii wrote:
>>> You are just listing the advantages of releasing frequently.  No one
>>> will argue with that, the problem is how to make that happen without
>>> hurting stability.
>>
>> I don't think it's possible not to sacrifice stability at all. It will
>>
>> most likely go down in XX.1 releases, at least to some extent.
> 
> The stability already goes down in NN.1 versions, that's why we always have a NN.2 version to follow.  We are talking about how much more it will decrease.  If you have practical suggestions for how to keep the instability in check while making more frequent releases, I'm all ears.

I mean will go down compared to the current situation.

But actually, if the period before branching, before stabilization, is 
also reduced proportionally, then fewer regressions will have a chance 
to sneak in. The odds of *some* regression remaining will likely go up, 
though.

For example, if we target, say, a new Emacs release every 6 months, then 
it will be 2 months development, 2 months stabilization, and 2 months 
prerelease (with new developments doing to the master for the last 4 
months).

With cycles like that, there will also be less temptation to "sneak that 
last feature in", or land an experimental feature later in the cycle. 
Developers will also moderate the risk themselves.

As for regression bugs remaining at each time, maybe the way to look at 
them is: If the period between when the regression happened and when it 
was reported will be longer than the time to the next minor release, 
maybe we can do the release now. And thus nominate fewer bugs to be 
actual blockers.

Right now Emacs releases, and even development branches, are fairly 
stable, so we have some margin for experimentation.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.