Re: Emacs-devel Digest, Vol 46, Issue 176

Re: Emacs-devel Digest, Vol 46, Issue 176

[Eric S. Raymond]

From: Dan Nicolaescu <dann@ics.uci.edu>
> [I think is better to refrain from fixing the code until the byte
> compiler issues are analyzed].

Noted.  I was about to go in and fix them, but I'll refrain.

From: Richard Stallman <rms@gnu.org>
> If it is a problem (and other people seem to disagree with you on
> this), it can't be helped. 

Yes, it can.  I learned earlier today that you expressed an intention
to hand off the Emacs maintainership after 22 was released.  If you
follow through on that, the new maintainer seems unlikely to have the 
peculiar restrictions you do.

I emphatically don't want the job.  But I'd like to see it pass
to someone who is at least willing to use a browser.  Then we could 
launch a web-based bug tracker on our Savannah space.  That and a
modern version-control system and a couple of monitor bots would be
good running start.

As you say, you have a lot of other things to do.  Actually, you shouldn't be
the Emacs lead maintainer for much the same reasons I can't be.  So pick 
someone you think has good judgment and let it go.

I strongly recommend that whoever it is should be at least fifteen
years younger than either of us, if that's possible among the
available candidates.  Given our image problems, I think the project
needs a front guy who can't possibly be dismissed as an old fart.

From: Richard Stallman <rms@gnu.org>
> An additional nice feature would be the ability to type C-c C-d and
> have it show you the change set corresponding to that point in
> ChangeLog.  (It could do that by matching dates and approximate
> matching against the log entry.)

Yes.  The best way to do that would actually be to synthesize history entries
in a new code repository from the existing Changelog data.  That actually 
wouldn't be very hard.  

Step 1: Use cvs2svn to move the CVS history to a Subversion repo.  The
key thing here is that it will group commits for us by date, content,
and developer name.

Step 2.  Write a script that grovels through all Changelogs and indexes
the entries by date and developer name.  It can then match those to the
commit groups generated in step 1 and edit them right into the commit 
history.

Result: We now have a sequence of commit groups in the history *each
one with the right block of commit data folded in*.  The CVS comments
and Changelogs have been merged.  This is the point at which we drop
the separate Changelog files, and the point at which you get your 
C-c C-d feature for free.

Step 4. History cleanup: Now we run through the commit sequence looking
for adjacent commits that should be merged, null commits, typos, and junk.
We fix those.

Step 5. Now we take the cleaned-up Subversion repo and lift it to whatever
VCS we actually want to use.

I'm willing to do this work.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 46, Issue 176

[Richard Stallman]

    I emphatically don't want the job.  But I'd like to see it pass
    to someone who is at least willing to use a browser.

I did not ask for your advice, and I am not going to take it.

Re: Emacs-devel Digest, Vol 46, Issue 176

[Richard Stallman]

    Yes.  The best way to do that would actually be to synthesize history entries
    in a new code repository from the existing Changelog data.  That actually 
    wouldn't be very hard.  

We will keep the ChangeLog file; that is a GNU Project convention.