Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 03/20/18 09:16 AM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: pierre.techoueyres@free.fr (Pierre Téchoueyres),
>>   johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Tue, 20 Mar 2018 14:10:51 +0800
>> 
>> >> Yes sorry I will do it next time.  You have found the right message :
>> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135
>> >
>> > I'm okay with that if Eric agrees.
>> 
>> Yes! My apologies again for the slowness. I really wanted to get a grasp
>> on CEDET and how it uses eieio-persist, to avoid causing more problems,
>> but realistically I'm not going to get there anytime soon. Also, the
>> fact that Pierre's tests fail exactly the same way with Emacs 25 and
>> Emacs 26+fix indicate that CEDET has other issues that need resolving
>> first.
>> 
>> What I would like to do is merge the fix/eieio-persistent branch. That
>> has new tests from Pierre (Pierre, have you signed FSF papers?), more
>> tests from me, and better error reporting for the restore process. The
>> commits that actually "do something" are bf4f34ac7 and 1ea9947ca3189.
>> 
>> Is that okay?
>
> Ouch!  Why are you waiting so long with such a large change?
>
> The changes in error/warning messages and in the test suite are okay
> to go, but I'm worried by the 2 changes that add a condition (where
> you went from (when ...) to (cond ...)).  Is this really necessary,
> and what problems do they solve?

I know... Mostly it took so long because of testing. The test suite
changes are there to test the new code, which directly models errors
currently in the wild, and they can't go in by themselves.

Very long story short, in Emacs 26 eieio objects went from being defined
as vectors to being defined as objects. This messed up how they are
serialized to disk using eieio-persistent. Two main consumers of
eieio-persistent (pcache and the Gnus registry) are currently broken
because of this. The `cond' statement is there to make sure that, in
these two packages, the objects are written correctly to disk.

>> If so, what's the proper merge strategy to use?
>
> It's up to you.  You can either merge or rebase, we don't care (and I
> don't want to get into a controversial discussion of which one is
> better).

I certainly don't have any opinion, I'd go with rebase, I guess.

Sorry about this,
Eric