unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Vincent Belaïche" <vincent.b.1@hotmail.fr>
To: EMACS devel list <emacs-devel@gnu.org>,
	Nicolas Petton <nicolas@petton.fr>
Cc: "Vincent Belaïche" <vincentb1@users.sourceforge.net>,
	"John Wiegley" <jwiegley@gmail.com>
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	[thread overview]
Message-ID: <84poprlh7c.fsf@gmail.com> (raw)

Kenavo Nico,

Le 02/08/2016 à 00:48, Nicolas Petton a écrit :
> Vincent Belaïche <vincent.b.1@hotmail.fr> 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	other threads:[~2016-08-02  8:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02  8:15 Vincent Belaïche [this message]
2016-08-02 14:51 ` [Emacs-diffs] emacs-25 8a38e94: Fix local printer set to left aligned string formatter Stefan Monnier
     [not found] <20160728174955.13840.3558@vcs.savannah.gnu.org>
     [not found] ` <20160728174955.752F622016B@vcs.savannah.gnu.org>
2016-08-01 16:26   ` John Wiegley
2016-08-01 22:03     ` Vincent Belaïche
2016-08-01 22:48       ` Nicolas Petton
2016-08-02 18:44       ` John Wiegley
2016-08-10  8:21         ` Vincent Belaïche
2016-08-11 17:31           ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84poprlh7c.fsf@gmail.com \
    --to=vincent.b.1@hotmail.fr \
    --cc=877fc0cdha.fsf@petton.fr \
    --cc=emacs-devel@gnu.org \
    --cc=jwiegley@gmail.com \
    --cc=nicolas@petton.fr \
    --cc=vincentb1@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).