Re: CEDET Merge

[Edward Steere]

Sent from my iPhone
> On 16 Jan 2017, at 11:13 PM, David Engster <address@hidden> wrote:
> 
> Edward John Steere writes:
>>> No, please do not merge Cogre. It is not a new module, was never part of
>>> Emacs and is not really actively developed anymore.
>>> 
>>> -David
>> 
>> Sure.
>> 
>> The plan is to start by getting the whole of Cedet compiling and
>> starting up in core and then taking a more deliberate approach to what
>> stays and goes.  I'm taking this approach because the alternatives
>> require a bit more historic knowledge of Cedet than I have.
>> 
>> Are you aware of a better approach?
> 
> The problem with this approach is that you loose lots of history for the
> changes that are applied. In Emacs this is especially problematic
> because of the copyright issues. So one will need at least a proper
> ChangeLog, saying which authors changed which functions, but the Emacs
> maintainers will have to say if that would suffice of if we need
> authorship information for each line that is applied.
> 
> So the "Right Way" would be to apply the upstream commits that happened
> since the last CEDET merge to the Emacs repo. I had a package for doing
> that, but it was based on Bazaar, so that went they way of the
> Dodo. It's called cedet-emacs-merge.el and is in the CEDET repo. I don't
> think it makes sense to port it to git, because we actually agreed some
> time ago to drop the CEDET repo altogether, so we would "only" need one
> final one-way merge. It's been on my TODO list for ages, and I'm really
> sorry that it still has not happened yet.
> 
> In my opinion, the first thing that should be done is to port the test
> suite to Emacs, meaning the unit and integration tests for Semantic and
> EDE, ripping out all tests for stuff that is not in Emacs. I already did
> that for EIEIO, but for Semantic and EDE a lot is missing. It will make
> it much easier to find regressions while doing the merge.
> 
> -David

Alright.  It shouldn't be too difficult to merge with the commit history intact 
and I agree wrt the tests so I'll make a start of porting those tonight.

Wrt the files which are in upstream but not in core do you have any experience 
with what ought to be merged?  There are newly supported project types and 
databases which look like they should probably be merged, but there are still 
more sources.  If not all of it is appropriate for the merge then perhaps we 
could look at moving future development to one or many ELPA packages.

(Apologies for the formatting, I'm writing this on my phone)