Re: Sync up the org in emacs master to org maint branch?

[David Engster]

Edward John Steere writes:
>  - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>    released; CEDET is at <some-hash-from-master-on-git>
>  - we update a registry somewhere indicating that Emacs 22.0 works with
>    <some-hash-from-master-on-git> and 22.1 works with
>    <some-hash-from-master-on-git>
>  - When we make updates to CEDET we mark 22.1 as working with
>    <some-new-hash-from-master-on-git> but we don't change that reference
>    for 22.0 (or any older versions)
>  - When someone complains that there's a bug in CEDET for 22.0 we
>    indicate that it's no longer supported and that they should update
>    Emacs to receive updates
>
> This process would almost be the same as what you get just by bundling
> CEDET with Emacs except that:
>
>  - You can get the latest CEDET *if* you have the latest Emacs

No. We have two branches: emacs-25 and master. The CEDET from master
will usually not work on any 25.x version.

>  - The version of CEDET for any particular version of Emacs is as far as
>    CEDET got before the next release of Emacs came out
>
> If this is what you were thinking of then please could you elaborate on
> what ended up being the problem which added more work.

First off, CEDET is currently *not* a package, although that notion gets
thrown around a lot. It is scattered across the Emacs code base:
lisp/cedet, admin/grammars, etc/srecode, documentation, and test
suite. All this needs to be packaged in a way so that it can be
integrated into Emacs during a normal checkout. It needs to build and
test in such a normal checkout, but also separately when installed from
ELPA, including grammar compilation. And you need this twice: one for
emacs-25, one for master, with the possiblity to merge between the two.

Then there's this "registry". No one has said how that should
work. "Submodules/Subtrees" are *not* a sufficient answer, they are just
tools. People will need to say how the *workflow* should be, including
such things like merges from stable, ChangeLog generation, AUTHORS,
NEWS, creating release tarballs, and so on. Once someone has written
this down *in detail*, we can discuss again if this indeed will make
things simpler and reduce our workload.

> I feel like there are aspects of CEDET which are still under
> development.

I hope so.

>> Well, we cannot really discuss this since there's no real plan how this
>> all should work. I can only speak from experience.
>
> We can still put ideas forward though.  Haven't come up with anything
> myself yet though.

Yes, you can, but it has a cost. Once again, the CEDET merge is stalled,
and we spend our time writing mails. I find this situation incredibly
frustrating.

>> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly
>> depend on Emacs "core" (whatever exactly that is), not the other way
>> round.
>
> I believe that one of the intentions of the move is to enforce this so
> we can't build bad dependencies -- am I wrong?

I think other modes should use Semantic.

> Perhaps I'm wrong, but to my mind the package approach would afford us
> with more testing before we get to the point of another release of
> Emacs.

If you develop on Emacs 'master', you can use all the new features (like
threading and FFI), but you loose testers on 25.x. A package won't
change that.

-David