GNU bug report logs - #69171
[JD Smith] Moving packages out of core to ELPA

Previous Next

Full log

Message #20 received at 69171 <at> debbugs.gnu.org (full text, mbox):

From: JD Smith <jdtsmith <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69171 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#69171: Moving packages out of core to ELPA
Date: Sat, 17 Feb 2024 19:59:18 -0500

[Message part 1 (text/plain, inline)]

> On Feb 17, 2024, at 5:42 PM, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> 
>>> I'd advocate moving IDLWAVE to ELPA, for the following reasons:
>> Sounds good, I'll add it GNU ELPA.
> 
> Hmm... I didn't realize the code really forked a long time ago.
> I'm not really comfortable replacing Emacs's code with Github's, since
> the one on Github lacks many changes.

Yep, this is a known issue.  Back in the day I had no idea how much would be added to the package when it went into core, and that happened without any communication with me, so years would go by.  When I'd notice how many changes had accumulated, I would sync what I could — things like typos and obsoleted functions — usually by hand, but there were lots of conflicts as development had continued and the versions had diverged.  It was frankly a bit frustrating.  I also found many changes to be nitpicky (preferring a certain style, etc.), or they removed backward or other compatibility I felt was still needed (XEmacs was explicitly supported for quite a while, for example).

> The last "sync" that I see mentioned dates back to Feb 2014 but already
> then the two code bases where quite different.

Yes, it was probably one of my by-hand, best-effort sync's, because so much had been added without my involvement.  In hindsight, it might have been easier to develop it fully outside of core, but I believe Carsten made that call before I had taken over from him, and I didn't really understand the implications at that time.

> I think we'd need to make an effort to re-sync the two (more
> specifically merge all the Emacs changes into the Github repository,
> I don't think the other direction is worth the trouble).

I agree.  I think this has even been suggested before, but I don't have the resources to take it on myself (though I'm happy to test it).  Maybe it's quasi-automate-able?  I notice many of the recent changes in core were broad across the board updates to lots of files, presumably with some kind of script; perhaps those could be rerun?

> I'm not even sure the Feb 2014 sync means that all previous changes in
> Emacs had been reflected into the Github version.

Yes, that's probably a fair assessment, as I was often doing these by hand.

> E.g. I took the following commit from Github:
> 
>    commit 883208713a36a4deae90df7c4c6fd76e296228ff (HEAD)
>    Author: JD Smith <jdtsmith <at> gmail.com>
>    Date:   Sun May 12 22:53:02 2013 -0400
> 
>        Doc/comments fixups.
> 
> which is the last commit before the "Major re-organization and cleanup"
> and then did:
> 
>    for h in $(cd ...emacs/main;
>               git log --pretty=oneline lisp/progmodes/idlwave.el |
>                   sed 's/ .*//');
>    do (cd ...emacs/tmp/; git checkout "$h" >/dev/null 2>&1)
>       echo "$h: $(diff -u ...emacs/tmp/lisp/progmodes/ . |
>                       grep -v '^Seulement dans' | wc)"
>    done
> 
> and this suggests that the closest commit on `emacs.git` might be:
> 
>    commit 627e0a14e8718945668b246f18053df0f82ed383
>    Author: Glenn Morris <rgm <at> gnu.org>
>    Date:   Thu Dec 3 17:14:33 2009 +0000
> 
>        (class): Restore still useful declaration.
>        Restore comment that is still relevant.
> 
> but the diff is still ~250kB (tho most of it is trivial removal
> of trailing whitespace).

There honestly hasn't been too much of significance added since that time.  I did the "major re-organization" you mentioned to make it more appealing for a new maintainer to take on 10 years ago (without success, sadly).  One option would be to try to achieve sync up to the commit just prior to that big reorg (which divided things up, creating 6 new files):

883208713a36a4deae90df7c4c6fd76e296228ff
Commit:     JD Smith <jdtsmith <at> gmail.com>
CommitDate: Mon Jan 27 15:27:46 2014 -0500

I guess another even cheaper option would be to take the current version in Emacs, make it a branch in my repo, and draw the ELPA package from that.  That's not ideal given the last date of divergence, but better than nothing I suppose. 

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.