emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] emacs-25 8a38e94: Fix local printer set to left aligne


From: Vincent Belaïche
Subject: Re: [Emacs-diffs] emacs-25 8a38e94: Fix local printer set to left aligned string formatter.
Date: Tue, 02 Aug 2016 10:15:35 +0200

Kenavo Nico,

Le 02/08/2016 à 00:48, Nicolas Petton a écrit :
> Vincent Belaïche <address@hidden> writes:
>
>> Well, I must admit that I am a naughty boy that has not filed any bug
>> before making this fix. I of course did some basic tests before
>> comitting and it was OK.
>
> Hi Vincent,
>
> The purpose of a release candidate is to provide a tarball as close as
> possible to the final release for testing, so once the first RC is
> out, only critical bug fixes should be pushed to the release branch.
>
> If a particular bug is blocking the release, then it's of course ok to
> commit a fix for it on emacs-25, but since it's not the case here,

Of course it is not a blocking bug. Without the correction you are just
prevented to configure a local printer using at the same time left
alignment and a string format specifier. Having said that, all the other
functions are OK AFAIK.

> I think that commits 8a38e94 and 3c97b0f should have been pushed to
> master instead.
>
>> IMHO taking this bug fix is not risky and that would make the local
>> printer feature more complete.
>
> I understand that, but who knows, even if your commit looks safe

It is only two lines of code, creating a new branch within a cond rather
than modifying any existing branch + I have made some tests. So yes, it
seems quite safe to take it.

> it might still introduce issues that you haven't seen yet :-)

That is correct, who knows... I has happened so many times to me in the
past that some correction makes some other problem appear.

Sometimes some bug is hidding some other bug by disabling some function,
and the program is more stable without the prior bug corrected.

So, I cannot tell the opposite: any change is a risk. I am not making a
fuss if people take the decision here not to take the correction in
emacs-25 even though would it depend only on me then I would take
it. This is *not* a critical correction and not being a frequent
contributor I just made the correction on emacs-25 without knowing it
was under release freeze because still this is a bug, not a new
function, and it has to be corrected anyhow.

BTW, is there any list with *LOW TRAFIC* on which release status
(freeze, etc...) is announced. Is the list info-gnu-emacs for that ? I
must say that I very seldom go on emacs-devel by lack of time.

>
> Cheers,
> Nico

À+,
  Vincent.


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus




reply via email to

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