[Top][All Lists]

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

bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in

From: Thomas Fitzsimmons
Subject: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Tue, 12 Jun 2018 21:39:37 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Thomas Fitzsimmons <address@hidden>
>> Date: Mon, 11 Jun 2018 21:55:48 -0400
>> Cc: Noam Postavsky <address@hidden>, address@hidden
>> I added the comment, bumped the soap-client version to 3.1.4 and pushed
>> the patch to master so that GNU ELPA will be regenerated tonight.  I
>> also backported the patch to the emacs-26 branch since it fixes a
>> functional regression.
> Thanks, but please in the future always ask before pushing stuff to
> the release branch.  Not every regression fix should go to emacs-26,
> only those which we consider "safe enough".

OK, will do, sorry about that.

> Also, if a change should be both on master and on emacs-26, push only
> to the latter, and it will be later merged to master together with
> other changes in emacs-26.  We only backport from master if initially
> we didn't intend for a change to be on emacs-26; otherwise we merge in
> the other direction.  (This is all explained in CONTRIBUTE under
> "Branches".)

Yes, I knew about the preferred emacs-26 -> master merge direction, but
in this case I wanted to get the soap-client change out to GNU ELPA ASAP
so that users could unbreak their Emacs 25 byte-code.  A GNU ELPA
rebuild of soap-client requires a push to master.

I guess I should have undertaken a full gitmerge run myself after having
had the patch reviewed for emacs-26 on emacs-devel; I considered doing
so, but I thought the master -> emacs-26-backport approach would be less
risky.  But in the future I'll attempt the gitmerge route in cases like


reply via email to

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