emacs-devel
[Top][All Lists]
Advanced

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

Re: CEDET merge


From: Stefan Monnier
Subject: Re: CEDET merge
Date: Sat, 06 Oct 2012 14:10:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

> Regarding the files which are both in Emacs and in CEDET: those are
> pretty much in sync now except for some compatibility code we have to
> keep for Emacs 23.1.. We also have some 'defadvice' hacks which we
> obviously cannot merge. For getting rid of the defadvices, some changes
> in Emacs core packages are needed, but I didn't have time to do that
> before the freeze (for example, getting proper help buffers for EIEIO
> classes and methods is pretty high on my TODO list).

OK.  I expect the removal of defadvice will require some changes to the
core, so probably some discussions to agree on how to do it, right?

> There are still some packages which are only in CEDET upstream for
> several reasons: They're either pretty new and not well tested, or are
> in our 'contrib' directory and don't have proper papers, or because they
> are a bit obscure (sorry Eric ;-) ) and well separated and hence would
> better fit into ELPA. For example, I think Cogre (for generating UML
> graphs) would be a good candidate for an ELPA package.

Adding those that can (i.e. that have the needed copyright paperwork) to
GNU ELPA would be great, yes.

> pretty painless now. The real work is in doing the 'diff|patch' thingy
> from Emacs to CEDET, but I've written a package for that which makes
> that fairly fast. All this should make it possible for me to do regular
> merges from now on, like the Gnus/Org people do.

Sounds good, thank you very much for that work.

> In addition, we are planning to move development of certain packages
> completely to Emacs trunk.  We already did that for Speedbar; the next
> candidates are EIEIO and mode-local.

Reminds me: we should start labeling the files not just with "who's the
maintainer" but also with "is there some external upstream".  Maybe by
adding a "Canonical-URL:" header for those externally-maintained files?

While we generally expect upstreams to take care of tracking the changes
we install, there are many cases where changes only make sense if
there's no external upstream.  E.g. switching from `cl' to `cl-lib',
where the upstream will probably not want to integrate this change
because they care about backward compatibility.

I have some approximate memory of which packages are externally
maintained and which don't, but it would help if I didn't have to rely
on that fuzzy memory.


        Stefan



reply via email to

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