emacs-devel
[Top][All Lists]
Advanced

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

Re[2]: Improving Emacs for writing code


From: Eric M. Ludlam
Subject: Re[2]: Improving Emacs for writing code
Date: Wed, 23 Apr 2008 10:05:14 -0400

>>> Chong Yidong <address@hidden> seems to think that:
>Stefan Monnier <address@hidden> writes:
>
>>>   I would be happy to see CEDET in Emacs.  It has always been a goal
>>> of mine, but I also know my long-term vision for CEDET does not always
>>> map onto what others want to see, and picking out only the tasty bits
>>> of CEDET may be hard without using the entire thing.
>>
>>>   Speedbar is in Emacs in a way that requires merging between our CVS
>>> trees.  The merges are difficult, which means I don't do them very
>>> often, because I can't really contribute to speedbar in Emacs proper.
>>
>> Yes, it's been problematic.
>>
>> I do think this problem can be significantly reduced on your side by
>> simply regularly merging from the Emacs-CVS tree, so the Emacs-CVS tree
>> may not always be up-to-date with yours, but yours is, so whenever we
>> need to sync the two, the merge has already been done.
>
>If this is agreeable, what's the next step?  Is CEDET in a state where
>we can dump it into the Emacs CVS tree, then work out whatever details
>need to be worked out?  That would be the fastest way to get things
>started up and running.
>
>Also, I'm not too clear about your explanation about the legal problem
>you mentioned.  If CEDET is added to Emacs, would your existing
>copyright assignment already cover it, or is there some other paperwork
>we need to work out?

Hi,

  All the core bits of CEDET from other authors should have up-to-date
papers for them, or are trivial.  All bits written by me need an
updated Employer disclaimer.

  If I get updated papers now, then any bug-fixing I do during the
merge will need yet more papers later, or I'll have to not
participate.  (I'm still cleaning up little things trying to put my
own release out.)

  The question isn't really "can" I get up to date papers, but how to
do a merge like this without getting lots and lots of papers.  I was
going to ask if I could get the typical time-bound release today, but
with a date a few months into the future, but the person I need to
talk to is on vacation this week.

  If it is possible to do a merge where the active truth is in the
CEDET sourceforge repository, that would likely make things much
easier for me in the short term.  When everyone feels it's "ready",
then I'll update my disclaimer, and it could be moved to it's new
home.

  Unfortunately, merging the build harness will not be easy, or really
possible in CEDET CVS tree since a goal for me will be at least one
more CEDET release for older Emacsen.

  Then there is the ongoing maintenance.  I'm not sure how Stefan's
suggestion would work for me.  I can imagine it being ok for a while
when all the changes are small.  I believe in periodic refactoring
which would make this more challenging.  If some smallish utility
outgrows its original purpose, I'll start moving and renaming large
chunks of code so things are more clear.  This would make
cross-merging difficult soon afterward.

  Also, unless it is fully automated, a daily or even weekly merge is
not reasonable for me.  My ability to work on Emacs related things is
sparse, and seasonal.  I typically go several months every fall and
other random times where I have trouble just keeping up with email.
See http://www.siege-engine.com for more on why that may be.

  There are also issues with the build harness, and how someone would
use the most recent "Eric" version against the most recent "Emacs"
version.

  I would very much like to find a way to have a single VC truth where
I can hack freely without impinging the rest of Emacs.  I can imagine
two ways to do this:

1) Truth is in the Emacs, and I find some way to participate there, or
   there is a branch where I can work.

2) Truth is in SourceForge, and changes by Emacs developers are
   checked into SourceForge.  I'd then need to find a way to get
   releases that allow a periodic mass-copy into the Emacs tree.

  Naturally, I like #2 the best, and you all will like #1 the best.

  Another option would be that I "eject" big parts out of CEDET.  I've
been thinking of ejecting speedbar for a while, as I really haven't
needed to change anything in there directly in a long time.  This has
a lot to do with ECB doing such a good job.  This could shrink the
overall size of CEDET to the areas with high-churn, and make merging
tasks smaller.

  This could all be a moot issue if someone wanted to volunteer as a
CEDET merge master keeping the repositories and build systems up to
date beyond the first merge stage.

  I apologize for making what should be a simple thing difficult.

  Eric

-- 
          Eric Ludlam:                       address@hidden
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net




reply via email to

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