bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov <dgutov@yandex.ru>]

On 11.05.2020 07:17, Eli Zaretskii wrote:
> On May 11, 2020 5:46:03 AM GMT+03:00, Dmitry Gutov <dgutov@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.