Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Wed 29 May 2019, Eric Abrahamsen wrote:
>
>> Hello reckless Gnus users!
>>
>> I'm working on the second half of the refactoring that broke everyone's
>> Gnus last time -- changing the hash tables to real hash tables, and
>> group names to decoded strings.
>>
>> In order to prevent a repeat performance of the last patch, I have a)
>> been much more careful about testing this one, and b) hope I can talk a
>> handful of you into helping me test.
>>
>> Basically you would check out a local copy of the scratch/gnus-decoded
>> branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
>> Emacs and do what you normally do in Gnus, and see if anything looks
>> funny. When you're tired of that, switch back to master, run "make"
>> again, and replace your backup .newsrc.eld file.
>
> If this set of changes modifies the file format of .newsrc.eld then you
> need a different strategy to ensure that users can continue to use their
> gnus data on both old and new gnus.

While I agree with the spirit of this, it's not how Gnus has done things
in the past. There is a `gnus-newsrc-file-version' variable and a
`gnus-convert-old-newsrc' function precisely for changing the file
format following a code upgrade. It's also generally understood that
syncing .newsrc.eld files between machines is risky and unpredictable.
Nor does keeping two copies of the data in different formats sound very
practical -- I don't know of any elisp code that does that.

However! I do agree that this change should probably use the existing
upgrade machinery, which means it would make most sense to hold off
until Gnus ups a version tick. All the tweaking I have in mind for Gnus
will probably warrant some sort of new version, at which point the
upgrade machinery actually prompts to do the conversion, and it should
be very obvious to users that they have a new .newsrc.eld version
(though actually I don't have anything else in mind that will affect
the file format).

So I'll go back to writing non-ascii group names in the gross old
encoding, slightly disappointing as that may be...

Eric