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

[Edward John Steere <edward.steere@gmail.com>]

>>  - 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.

In the process which I proposed we would be developing against the most
recently released Emacs.  I now see that there's a trade off.  If we
were to go with my scheme then users would have access to the latest
version, but we would:
 1. miss out on the new features being developed on the Emacs master
    branch (which CEDET stands to gain a lot from);
 2. have to endure a difficult and error prone release process every time
    Emacs is released because that's not what all the testing is done
    against;

If we go ahead and merge it in then we would be able to benefit from all
the new Emacs features and the release would be less painful.  Of course
our users would still have to wait for the latest features, but at least
it would be worth the wait because we would be able to consider using
features like threading.

>>  - 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.

Yes, this would be a pain.  I'm in favour of Phillip's approach in which
the packages are self contained somewhere in the Emacs source tree.
This would eliminate the need for a complicated copying process and
eliminate the problem of where things go and what files should be
updated.  No other folder would be touched because a package contains
it's own source, documentation etc.  Unfortunately the idea isn't
gaining a lot of traction.  I'm not satisfied that the alternative would
make things easier for anyone because, as you say, it would need to
describe a complex copying process which intertwines CEDET with various
parts of Emacs.

> 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 haven't heard the registry mentioned before.  I mentioned it as a
detail required by my process for supporting multiple versions, but I'm
beginning to think that it's the wrong line of thought to pursue.

>>> 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.

In lieu of any input from others the best we have is Phillip's idea of
using Elpa.  That solves how the files are copied in and compiled.

>>> 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.

Agreed.  I mentioned this in my response to Stefan's email.  Shouldn't
we then consider moving it out of CEDET in Emacs?

>> 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.

Yes.  As I said earlier in this email I'm now starting to appreciate
this problem.  Perhaps it's worth considering which aspects of CEDET
would really benefit from being integrated with Emacs and which could
live without the latest features (and be turned into packages).

There are four parts to CEDET which I'm aware of (at least in the CEDET
which is included in Emacs):
 1. Semantic
 2. Semanticdb
 3. EDE
 4. Srecode

I think that the key parts are Semantic and Semanticdb.  What if we
merged Semantic and Semanticdb into Emacs proper (i.e. not under a
folder named cedet in the source tree) and worked on turning EDE and
Srecode into packages which are included for distribution?

The only obstacle I can think of is that there are some features in
Semantic (ia and db) which rely on project variables (such as the
location of system includes).  We could consider decoupling Semantic to
solve this problem.  e.g. by providing an interface to which other modes
can publish known information about the context of a source file in a
project.