MH-E 7.4.4 checked in

MH-E 7.4.4 checked in

[Bill Wohler]

MH-E is the Emacs interface to the MH mail system. It offers all the
functionality of MH, the visual orientation and simplicity of use of a
GUI, and full integration with Emacs and XEmacs, including thorough
configuration and online help. Read on for more details.

Project home page at: http://mh-e.sourceforge.net/.

Version 7.4.4 addresses programmatic issues from the FSF and prepares
MH-E for inclusion into an impending GNU Emacs release (21.4). There
are no user-visible changes (unless you are using XEmacs on DOS or
don't have the cl package installed). Filenames are now unique in
their first 8 characters (DOS 8.3 requirement). The runtime dependency
on the cl package has been removed. Desktop saving and restoration
code moved here from desktop.el.

--
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> Date: Mon, 12 Jul 2004 20:26:43 -0700
> From: Bill Wohler <wohler@newt.com>
> 
> Version 7.4.4 addresses programmatic issues from the FSF and prepares
> MH-E for inclusion into an impending GNU Emacs release (21.4). There
> are no user-visible changes (unless you are using XEmacs on DOS or
> don't have the cl package installed). Filenames are now unique in
> their first 8 characters (DOS 8.3 requirement). The runtime dependency
> on the cl package has been removed. Desktop saving and restoration
> code moved here from desktop.el.

Thanks.

It looks like you forgot to either "cvs add" or "cvs ci" the new file
mh-xemacs.el, because "cvs up" deletes mh-xemacs-*.el, but doesn't
bring mh-xemacs.el.  Also, the files MH-E-NEWS and README (mentioned
by mh-e/ChangeLog) seem to not be in the repository, either.

Re: MH-E 7.4.4 checked in

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 12 Jul 2004 20:26:43 -0700
> > From: Bill Wohler <wohler@newt.com>
> > 
> > Version 7.4.4 addresses programmatic issues from the FSF and prepares
> > MH-E for inclusion into an impending GNU Emacs release (21.4). There
> > are no user-visible changes (unless you are using XEmacs on DOS or
> > don't have the cl package installed). Filenames are now unique in
> > their first 8 characters (DOS 8.3 requirement). The runtime dependency
> > on the cl package has been removed. Desktop saving and restoration
> > code moved here from desktop.el.
> 
> Thanks.
> 
> It looks like you forgot to either "cvs add" or "cvs ci" the new file
> mh-xemacs.el, because "cvs up" deletes mh-xemacs-*.el, but doesn't
> bring mh-xemacs.el.

No, I did not include it in the GNU Emacs repository because it is not
used by GNU Emacs.

>                      Also, the files MH-E-NEWS and README (mentioned
> by mh-e/ChangeLog) seem to not be in the repository, either.

The README, which explains how to install MH-E from the tarball at
SourceForge, isn't needed by GNU Emacs users who are using the built-in
version of MH-E.

I did these things to minimize user confusion, although it appears it
was at the expense of maintainer confusion ;-).

MH-E-NEWS is in the etc directory.

--
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> Date: Mon, 12 Jul 2004 21:24:21 -0700
> From: Bill Wohler <wohler@newt.com>
> 
> > It looks like you forgot to either "cvs add" or "cvs ci" the new file
> > mh-xemacs.el, because "cvs up" deletes mh-xemacs-*.el, but doesn't
> > bring mh-xemacs.el.
> 
> No, I did not include it in the GNU Emacs repository because it is not
> used by GNU Emacs.
> 
> >                      Also, the files MH-E-NEWS and README (mentioned
> > by mh-e/ChangeLog) seem to not be in the repository, either.
> 
> The README, which explains how to install MH-E from the tarball at
> SourceForge, isn't needed by GNU Emacs users who are using the built-in
> version of MH-E.
> 
> I did these things to minimize user confusion, although it appears it
> was at the expense of maintainer confusion ;-).
> 
> MH-E-NEWS is in the etc directory.

The problem is that all these files are mentioned in
lisp/mh-e/ChangeLog, so it is very confusing not to find them, or have
them in another directory.

I understand the reason for having the same ChangeLog in Emacs that
you have in your primary repository, but given that you already
move/delete some of the files (as you explained above), perhaps
editing ChangeLog that is checked into the Emacs CVS would not be such
a bad idea.

Alternatively, perhaps consider adding mh-xemacs.el, README and
MH-E-NEWS to lisp/mh-e anyway.  They shouldn't do too much harm, I
think; etc/NEWS could say something like "for changes in MH-E see
lisp/mh-e/MH-E-NEWS".

Re: MH-E 7.4.4 checked in

[Miles Bader]

On Tue, Jul 13, 2004 at 09:55:52PM +0200, Eli Zaretskii wrote:
> The problem is that all these files are mentioned in
> lisp/mh-e/ChangeLog, so it is very confusing not to find them, or have
> them in another directory.
> 
> I understand the reason for having the same ChangeLog in Emacs that
> you have in your primary repository, but given that you already
> move/delete some of the files (as you explained above), perhaps
> editing ChangeLog that is checked into the Emacs CVS would not be such
> a bad idea.

Please, no, it's an extremely bad idea!  This sort of thing just make life
(very) painful for later merging.

People edit past history in ChangeLogs _way_ too much already.  Given that
Emacs hackers are really not going to concern themselves very much about any
file called "*-xemacs*", I think there's little harm in saying "ah well" in
this case, and KEEPING THE CHANGELOG PREPEND-ONLY.

Please.

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: MH-E 7.4.4 checked in

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> wrote:

> The problem is that all these files are mentioned in
> lisp/mh-e/ChangeLog, so it is very confusing not to find them, or have
> them in another directory.

I understand. I'll propose a workaround below.

>                                                         perhaps
> editing ChangeLog that is checked into the Emacs CVS would not be such
> a bad idea.

Having two versions of the same file seems like a bad idea to me. It
would cause initial work to write scripts to strip out entries for these
files and it would certainly break my scripts that ensure that Emacs
maintainers haven't modified MH-E files without my knowledge. Who knows
what other problems would ensue.

> Alternatively, perhaps consider adding mh-xemacs.el, README and
> MH-E-NEWS to lisp/mh-e anyway.  They shouldn't do too much harm, I
> think; etc/NEWS could say something like "for changes in MH-E see
> lisp/mh-e/MH-E-NEWS".

Since MH-E-NEWS has been in the etc directory since the dawn of man, I
don't think it should be moved unless its location was in violation of a
new general policy.

I think I have an idea that should satisfy your requirements.

I could create a lisp/mh-e/README.Emacs that would explain the
discrepancies. README.Emacs would explain that the directory is
maintained at SourceForge as a standalone package and therefore the
ChangeLog contains mention of files that are not needed and therefore
not found in the Emacs distribution. Having this file might not be such
a bad idea anyway since it could also explain that MH-E installs images
in lisp/toolbar and lisp/mail as well.

How does this sound to you?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> Date: Tue, 13 Jul 2004 22:09:56 -0700
> From: Bill Wohler <wohler@newt.com>
> 
> I could create a lisp/mh-e/README.Emacs that would explain the
> discrepancies. README.Emacs would explain that the directory is
> maintained at SourceForge as a standalone package and therefore the
> ChangeLog contains mention of files that are not needed and therefore
> not found in the Emacs distribution.

I'm not sure this is worth the effort.  Having the absense of some
files explained in yet another file will not necessarily help to
eliminate confusion.

But if no one else is bothered by the fact that mh-e/ChangeLog
mentions files that are not in the tarball, perhaps we should simply
ignore the issue.

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

I have another problem with mh-e files: "make recompile" in the lisp
subdirectory fails to compile these 6 files:

   mh-comp.el, mh-e.el, mh-utils.el, mh-funcs.el, mh-junk.el, mh-seq.el

Every one of these 6 files fails to compile with messages like the
ones reproduced below:

    Checking d:/gnu/new/emacs/lisp/mh-e...
    Compiling d:/gnu/new/emacs/lisp/mh-e/mh-comp.el...
    Source file `d:/gnu/new/emacs/lisp/mh-e/mh-e.el' newer than byte-compiled file
    Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file
    Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file

    In toplevel form:
    mh-e/mh-comp.el:35:1:Error: Symbol's function definition is void: mh-require-cl

Re: MH-E 7.4.4 checked in

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> Every one of these 6 files fails to compile with messages like the
> ones reproduced below:
>
>     Checking d:/gnu/new/emacs/lisp/mh-e...
>     Compiling d:/gnu/new/emacs/lisp/mh-e/mh-comp.el...
>     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-e.el' newer than byte-compiled file
>     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file
>     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file

Remove the old byte compiled files first.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Fri, 16 Jul 2004 14:39:47 +0200
> 
> Remove the old byte compiled files first.

Thanks.

However, this doesn't help: the compilation of each one of these 6
files now dies with a different message:

  In toplevel form:
  mh-e/mh-utils.el:55:1:Error: Invalid function: (macro lambda nil (if (eq (car (macroexpand (quote (setf (gethash foo bar) baz)))) (quote cl-puthash)) (\` (require (quote cl))) (\` (eval-when-compile (require (quote cl))))))

(Anyway, I don't think that users should be required to remove old
.elc files in this case.)

Re: MH-E 7.4.4 checked in

[Satyaki Das]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Andreas Schwab <schwab@suse.de>
> > Date: Fri, 16 Jul 2004 14:39:47 +0200
> > 
> > Remove the old byte compiled files first.
> 
> Thanks.
> 
> However, this doesn't help: the compilation of each one of these 6
> files now dies with a different message:
> 
>   In toplevel form:
>   mh-e/mh-utils.el:55:1:Error: Invalid function: (macro lambda nil (if (eq (car (macroexpand (quote (setf (gethash foo bar) baz)))) (quote cl-puthash)) (\` (require (quote cl))) (\` (eval-when-compile (require (quote cl))))))

A new macro mh-require-cl was added.  As a result you need to
remove the old .elc files before proper compilation of Emacs can
happen.

I just removed all the *.elc files in lisp/mh-e and could
recompile without any problems.  Is this what you tried?

Satyaki

Re: MH-E 7.4.4 checked in

[Stefan]

> A new macro mh-require-cl was added.  As a result you need to remove the
> old .elc files before proper compilation of Emacs can happen.

Changing a macro's definition or worse changing a function into a macro
does require manual intervention (removal of some .elc files) but
adding a new macro should not require removing .elc files.

The reason why it turned out to be necessary in this case is because
mh-utils.el (where mh-require-cl is defined) and mh-customize.el require
each other.
This can be seen in the error messages posted by Eli:

     Checking d:/gnu/new/emacs/lisp/mh-e...
     Compiling d:/gnu/new/emacs/lisp/mh-e/mh-comp.el...
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-e.el' newer than byte-compiled file
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file
     Source file `d:/gnu/new/emacs/lisp/mh-e/mh-utils.el' newer than byte-compiled file

Notice how mh-utils.el appears twice: once first because it's required by
mh-e, and a second time because while loading mh-utils, it required
mh-custom which itself required mh-utils (which still hadn't been
provided).

I think this double-loading of mh-utils should be fixed.  A good way to do
that is to change mh-custom and mh-utils so they don't mutually require
each other.

By the way, the patch below is necessary if the double-loading of
mh-utils.el is fixed.


        Stefan


--- mh-utils.el	16 Jul 2004 10:18:02 -0400	1.6
+++ mh-utils.el	16 Jul 2004 11:13:12 -0400	
@@ -34,8 +34,9 @@
 ;;; Code:
 
 ;; Is this XEmacs-land? Located here since needed by mh-customize.el.
-(defvar mh-xemacs-flag (featurep 'xemacs)
-  "Non-nil means the current Emacs is XEmacs.")
+(eval-and-compile
+  (defvar mh-xemacs-flag (featurep 'xemacs)
+  "Non-nil means the current Emacs is XEmacs."))
 
 ;; The Emacs coding conventions require that the cl package not be required at
 ;; runtime. However, the cl package in versions of Emacs prior to 21.4 left cl

Re: MH-E 7.4.4 checked in

[Satyaki Das]

Stefan <monnier@iro.umontreal.ca> writes:

> The reason why it turned out to be necessary in this case is because
> mh-utils.el (where mh-require-cl is defined) and mh-customize.el require
> each other.

OK, I will see if I can fix this.  We tried it once before and
didn't make much headway.

Thanks,
Satyaki

Re: MH-E 7.4.4 checked in

[Bill Wohler]

Satyaki Das <satyaki@theforce.stanford.edu> wrote:

> Stefan <monnier@iro.umontreal.ca> writes:
> 
> > The reason why it turned out to be necessary in this case is because
> > mh-utils.el (where mh-require-cl is defined) and mh-customize.el require
> > each other.
> 
> OK, I will see if I can fix this.  We tried it once before and
> didn't make much headway.

Thanks to Stefan for the lead and Satayki for fixing the problem. I
trust that you'll get it this time, perhaps with help from Eli and
Stefan. When it's done, I'll rev MH-E and update Emacs.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: MH-E 7.4.4 checked in

[Richard Stallman]

    I think this double-loading of mh-utils should be fixed.  A good way to do
    that is to change mh-custom and mh-utils so they don't mutually require
    each other.

I agree, that would make things much cleaner.
Bill, can you do that?

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> From: "Satyaki Das" <satyaki@theforce.stanford.edu>
> Date: Fri, 16 Jul 2004 07:09:32 -0700
> > 
> >   In toplevel form:
> >   mh-e/mh-utils.el:55:1:Error: Invalid function: (macro lambda nil (if (eq (car (macroexpand (quote (setf (gethash foo bar) baz)))) (quote cl-puthash)) (\` (require (quote cl))) (\` (eval-when-compile (require (quote cl))))))
> 
> A new macro mh-require-cl was added.  As a result you need to
> remove the old .elc files before proper compilation of Emacs can
> happen.
> 
> I just removed all the *.elc files in lisp/mh-e and could
> recompile without any problems.  Is this what you tried?

No, I removed only the 6 *.elc files whose recompilation failed.

I now removed all the *.elc files in the mh-e directory, and then
"make recompile" did work.  Thanks.

I still think that either MH-E or lisp/Makefile.in (or both) should be
changed so as not to require such manual deletions.  We have a number
of other Lisp packages (Eshell, CC-Mode, Ediff, etc.) with subtle
dependencies among their *.el files, but "make recompile" always does
TRT for them.

Re: MH-E 7.4.4 checked in

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> I still think that either MH-E or lisp/Makefile.in (or both) should be
> changed so as not to require such manual deletions.  We have a number
> of other Lisp packages (Eshell, CC-Mode, Ediff, etc.) with subtle
> dependencies among their *.el files, but "make recompile" always does
> TRT for them.

You have been lucky then.  In general, if you add a macro to one file and
use it in another file whose name is alphabetically before the other
you'll get (more or less silently) a non-working result during recompile,
since loading the old version of the byte compiled files will not define
the macro.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 17 Jul 2004 13:21:14 +0200
> 
> In general, if you add a macro to one file and use it in another
> file whose name is alphabetically before the other [...]

Perhaps one should avoid doing that, then.

Re: MH-E 7.4.4 checked in

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Date: Sat, 17 Jul 2004 13:21:14 +0200
>> 
>> In general, if you add a macro to one file and use it in another
>> file whose name is alphabetically before the other [...]
>
> Perhaps one should avoid doing that, then.

The sort order of filenames can depend on the locale.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: MH-E 7.4.4 checked in

[Stefan]

> I still think that either MH-E or lisp/Makefile.in (or both) should be
> changed so as not to require such manual deletions.  We have a number
> of other Lisp packages (Eshell, CC-Mode, Ediff, etc.) with subtle
> dependencies among their *.el files, but "make recompile" always does
> TRT for them.

As Andreas indicated, it doesn't alway DTRT.  And fixing the Makefile to
DTRT is difficult.
Ways to try to fix it:
- look at `provide' and `require' statements to make up
  Makefile dependencies.  I had this working at some point (GNU-only) but
  it wasn't great: lots of unnecessary recompilation, lots of circular
  dependencies, and it still misses lots of dependencies (for files that
  are preloaded (and hence not `require'd) or for autoloaded thingies).
- during byte-compilation remember which macro we expand and after writing
  the .elc file, write a foo.elc.d file listing the other files it
  depended on.  Kind of like gcc's `-MD' argument.
- during byte-compilation, a `require' loads the .el file if it is younger
  than the .elc.  Maybe even load the.el file if it is more recent than the
  .elc even if the .elc has already been (pre)loaded.


        Stefan

Re: MH-E 7.4.4 checked in

[Richard Stallman]

      We have a number
    > of other Lisp packages (Eshell, CC-Mode, Ediff, etc.) with subtle
    > dependencies among their *.el files, but "make recompile" always does
    > TRT for them.

We should try to get rid of these dependencies,
and certainly not introduce any more.

If I had had time to maintain Emacs more thoroughly,
including studying how these things work, I would probably
have insisted on redesigning them.  But I didn't have time,
and I don't really know about these problems.

Re: MH-E 7.4.4 checked in

[Kai Grossjohann]

"Eli Zaretskii" <eliz@gnu.org> writes:

> I understand the reason for having the same ChangeLog in Emacs that
> you have in your primary repository, but given that you already
> move/delete some of the files (as you explained above), perhaps
> editing ChangeLog that is checked into the Emacs CVS would not be such
> a bad idea.

What I do with Tramp is that I merge the *.el files into the Emacs
repository and then, manually, compose ChangeLog entries describing
the changes.

So usually the ChangeLog in the Tramp repository might have many
entries between two releases, whereas the Emacs repository typically
just has two entries for each release (one for Michael's changes and
one for my own changes).  The ChangeLog entries in the Emacs
repository summarize the Tramp entries in such a way that, for
example, changes made and then reverted are not described (since the
intermediate version never showed up in the Emacs repository).

What do people think about this?

The purpose of this posting is NOT to suggest the Tramp method for
everyone!  I merely think it would be good if add-on packages
maintained outside the Emacs CVS tree would all be handled in a
similar fashion, for consistency's sake.

Kai

Re: MH-E 7.4.4 checked in

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> The ChangeLog entries in the Emacs
> repository summarize the Tramp entries in such a way that, for
> example, changes made and then reverted are not described (since the
> intermediate version never showed up in the Emacs repository).
> 
> What do people think about this?

I like the way it's done for Tramp, as you basically get one ChangeLog
entry for one CVS commit.  Also it's logical since tramp resides in
one of emacs' standard lisp directories (lisp/net).

However, if a package (like Gnus or MH-E) has its own subdirectory and
its own ChangeLog file, that is ok too.  

But as has been seen for Gnus, it is not easy to know what changes
were made to the emacs repository (and not backported to Gnus
repository), and which changes came from Gnus repository and really
doesn't correspond to any specific CVS commit in emacs repository.

That's the main reason (IIRC) why Gnus in emacs repository hasn't
yet been updated to Oort gnus.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: MH-E 7.4.4 checked in

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> But as has been seen for Gnus, it is not easy to know what changes
> were made to the emacs repository (and not backported to Gnus
> repository), and which changes came from Gnus repository and really
> doesn't correspond to any specific CVS commit in emacs repository.
>
> That's the main reason (IIRC) why Gnus in emacs repository hasn't
> yet been updated to Oort gnus.

That and 134,295 other bad-for-merging changes....

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: MH-E 7.4.4 checked in

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> > That's the main reason (IIRC) why Gnus in emacs repository hasn't
> > yet been updated to Oort gnus.
> 
> That and 134,295 other bad-for-merging changes....

Why do we need to merge those changes?

Don't people get along just fine with using an "unmodified" Oort Gnus
on CVS emacs ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: MH-E 7.4.4 checked in

[Miles Bader]

On Wed, Jul 14, 2004 at 03:22:42PM +0200, Kim F. Storm wrote:
> > That and 134,295 other bad-for-merging changes....
> 
> Why do we need to merge those changes?
> 
> Don't people get along just fine with using an "unmodified" Oort Gnus
> on CVS emacs ?

Sure (including me).

But there do seem to be `real' changes in the emacs version -- many of them
are fairly trivial (e.g., spelling corrections, or updating Gnus not to use
some obsolete feature), and there are some which appear non-trivial but
which I don't understand.

Many changes are also backported back-and-forth, so gnus already has _some_
of these changes.

If I had a better handle on which changes were really important, it would be
simpler to do as you say (and forward-port only those important changes), but
I don't really, and the sheer quantity of changes makes it hard to spend a
lot of time to analyze each one.

As it is, though, it's looking like no matter what I do, something will end
up broken, so the "give up and drop most of the emacs changes" approach is
looking better and better.  However, I'd still like  to munch on it for a
while (I haven't had much time to spend on this recently) before deciding
that.

BTW, once this is done, I'm going to do my damnedest to keep emacs from
falling so far out of sync with upstream...

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Gnus integration (was: MH-E 7.4.4 checked in)

[Stefan]

> BTW, once this is done, I'm going to do my damnedest to keep emacs from
> falling so far out of sync with upstream...

I think the problem is that upstream fell out of sync.
We should really try to avoid any local change that the upstream
maintainer rejects, otherwise it becomes unmaintainable (I've seen it in
miniature with cperl-mode.el, and I'd rather not think about what it can
turn into with something like Gnus).

I think the best way forward is to check in an unmodified Oort Gnus along
with a "best effort" list of things that might need merging (a big patch
file, maybe).  Then ask Dave Love what changes he made on the original Gnus
version before checking it in (in high-level terms) so we can assess what
needs to be redone.  Then we can all try to help select what really needs
to be merged and do the merge (I can easily merge in the patches that
I installed, for example).


        Stefan

Re: Gnus integration (was: MH-E 7.4.4 checked in)

[Stefan Monnier]

> I think the best way forward is to check in an unmodified Oort Gnus along
> with a "best effort" list of things that might need merging (a big patch
> file, maybe).  Then ask Dave Love what changes he made on the original Gnus
> version before checking it in (in high-level terms) so we can assess what
> needs to be redone.  Then we can all try to help select what really needs
> to be merged and do the merge (I can easily merge in the patches that
> I installed, for example).

And of course, my first paragraph (not quoted here) implies that any change
that we thus apply to the unmodified Oort Gnus should be carefully passed
on to the Gnus maintainers for inclusion.

Some may think "this is too much work", but I think instead we should at it
as a good way to make sure we concentrate on the really important changes.


        Stefan

Re: Gnus integration (was: MH-E 7.4.4 checked in)

[Luc Teirlinck]

Stefan Monnier wrote:

   I think the problem is that upstream fell out of sync.
   We should really try to avoid any local change that the upstream
   maintainer rejects, otherwise it becomes unmaintainable (I've seen it in
   miniature with cperl-mode.el, and I'd rather not think about what it can
   turn into with something like Gnus).

I indeed believe that no changes (in Emacs CVS) to packages
distributed with Emacs should be made without discussing them with the
maintainers of those packages.  People making changes to Emacs CVS
usually do not worry about all the compatibility issues that the
maintainers of those packages do worry about a lot, so merging changes
may indeed become very non-trivial.  For instance, my original
proposed patch to tramp.el did not take compatibility issues into
account, but, after discussing this with Kai, the patch I actually
committed does, so that there should be no merging difficulties.  If
the maintainers of the package know of, and approve of, the change in
its exact form, why should they _not_ include it in their own CVS
version?  In some cases, there might actually be some reasons, like
philosophical differences, say about run-time loading of cl in the
case of cc-mode, but even in those cases, I believe maintainers should
be aware of the changes made to Emacs CVS.

Sincerely,

Luc.

Gnus update (was: MH-E 7.4.4 checked in)

[Reiner Steib]

On Thu, Jul 15 2004, Miles Bader wrote:

> On Wed, Jul 14, 2004 at 03:22:42PM +0200, Kim F. Storm wrote:
[...]
>> Don't people get along just fine with using an "unmodified" Oort Gnus
>> on CVS emacs ?
>
> Sure (including me).

ACK.  Some days ago someone posted a User-Agent statistics for the
German Gnus newsgroup (<news:7jta41jk.fsf@sanis.schnuerpel.net>).  It
showed that many people already use Gnus 5.10 (or "No Gnus", the
current development version) together with Emacs 21.3.50.

> But there do seem to be `real' changes in the emacs version -- many of them
> are fairly trivial (e.g., spelling corrections, or updating Gnus not to use
> some obsolete feature), and there are some which appear non-trivial but
> which I don't understand.
[...]
> If I had a better handle on which changes were really important, it would be
> simpler to do as you say (and forward-port only those important changes), but
> I don't really, and the sheer quantity of changes makes it hard to spend a
> lot of time to analyze each one.

I would assume that all *important* changes committed by Dave and
ShengHuo in Emacs' CVS have also been applies in Gnus CVS.  But
probably this has been done after the v5-8 point which you considered
upto now.

> As it is, though, it's looking like no matter what I do, something will end
> up broken, so the "give up and drop most of the emacs changes" approach is
> looking better and better.  However, I'd still like  to munch on it for a
> while (I haven't had much time to spend on this recently) before deciding
> that.

Most of the Gnus changes in Emacs were committed by Stefan Monnier,
Juanma Barranquero and Andreas Schwab.  If we go for this approach (I
think we will have to do this eventually), I'm optimistic that these
people will point it out if important changes got lost.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Andreas Schwab]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Most of the Gnus changes in Emacs were committed by Stefan Monnier,
> Juanma Barranquero and Andreas Schwab.  If we go for this approach (I
> think we will have to do this eventually), I'm optimistic that these
> people will point it out if important changes got lost.

None of my changes are needed for Oort Gnus.  Actually I have been using
Oort Gnus all the time since its first release.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

    I would assume that all *important* changes committed by Dave and
    ShengHuo in Emacs' CVS have also been applies in Gnus CVS.

If they were committed by ShengHuo, I expect he took care of the same
problems in the separate Gnus repository too.  That is because he is
one of the main Gnus developers.  Is there a specific reason to expect
that Dave's changes are already in the separate Gnus repository?

    Most of the Gnus changes in Emacs were committed by Stefan Monnier,
    Juanma Barranquero and Andreas Schwab.

Are these people willing to adapt their changes to the latest Gnus?

    None of my changes are needed for Oort Gnus.  Actually I have been using
    Oort Gnus all the time since its first release.

    Andreas.

That simplifies matters--what about Stefan and Juanma's changes?

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Stefan Monnier]

>     Most of the Gnus changes in Emacs were committed by Stefan Monnier,
>     Juanma Barranquero and Andreas Schwab.
> Are these people willing to adapt their changes to the latest Gnus?

I'd expect so.  My changes are fairly few and some of them have already
been included in Oort Gnus.  The rest should be easy (for me) to adapt.
IIRC I even have one or two minor changes that I haven't committed yet
because I prefer to do that after the new Gnus is installed (if it's still
necessary at that point).


        Stefan

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

    > Are these people willing to adapt their changes to the latest Gnus?

    I'd expect so.  My changes are fairly few and some of them have already
    been included in Oort Gnus.  The rest should be easy (for me) to adapt.
    IIRC I even have one or two minor changes that I haven't committed yet
    because I prefer to do that after the new Gnus is installed (if it's still
    necessary at that point).

How about putting the latest Gnus into a branch, so that you and
others can merge your changes into it?

Re: Gnus update

[Reiner Steib]

On Fri, Jul 16 2004, Richard Stallman wrote:

>     I would assume that all *important* changes committed by Dave and
>     ShengHuo in Emacs' CVS have also been applies in Gnus CVS.
>
> If they were committed by ShengHuo, I expect he took care of the same
> problems in the separate Gnus repository too.  That is because he is
> one of the main Gnus developers.  Is there a specific reason to expect
> that Dave's changes are already in the separate Gnus repository?

Dave has write access to Gnus' CVS and often does commits there.

In a private mail (to Miles, Lars, ShengHuo and me) about this topic
Dave wrote that he some changes for the benefit of Emacs 22
(encoding/API issues).

Apart from that, I see from Gnus' ChangeLog that he installed many
changes in Gnus 5.10 related to message de/encoding (rfc2047.el,
mm-*.el, ...).  IIRC there also were entries in Emacs'
lisp/gnus/ChangeLog from Dave mentioning "(partial) sync with Gnus" or
similar.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Richard Stallman]

    Apart from that, I see from Gnus' ChangeLog that he installed many
    changes in Gnus 5.10 related to message de/encoding (rfc2047.el,
    mm-*.el, ...).  IIRC there also were entries in Emacs'
    lisp/gnus/ChangeLog from Dave mentioning "(partial) sync with Gnus" or
    similar.

That sounds good.

Re: Gnus update

[Richard Stallman]

    Apart from that, I see from Gnus' ChangeLog that he installed many
    changes in Gnus 5.10 related to message de/encoding (rfc2047.el,
    mm-*.el, ...).  IIRC there also were entries in Emacs'
    lisp/gnus/ChangeLog from Dave mentioning "(partial) sync with Gnus" or
    similar.

That sounds good.

	 In Fundamental mode, but not in Text mode, an indented line also
	 starts a new paragraph.

    This statement is also not true.  The regexp does not recognise
    indentation as starting paragraphs, only blank lines.

How about this?

      @kbd{M-@{} moves to the beginning of the current or previous
    paragraph, while @kbd{M-@}} moves to the end of the current or next
    paragraph.  Blank lines and text-formatter command lines separate
    paragraphs and are not considered part of any paragraph.  In Indented
    Text mode, but not in Text mode, an indented line also starts a new
    paragraph.

Thanks.

Re: Gnus update

[Dave Love]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

>> Is there a specific reason to expect
>> that Dave's changes are already in the separate Gnus repository?

There's specific reason to think they aren't (all).  If I remember
correctly, people who know more about Mule than I do rejected some
Mule-related changes, probably from the Emacs 22 branch.  I don't
remember exactly, though.

If this is about installing Gnus 5.10 in Emacs , you should be aware
that significant changes were installed without copyright papers on
file.  I don't have examples, but larsi complained about it on the
Gnus list, and I spotted examples subsequently.  Papers may or may not
have been got since, but that needs to be checked.  (It was a real
pain doing that for Gnus 5.9 and re-writing some bits.  Part of the
trouble is that CVS log entries are often unhelpful.)

Also, the latest 5.10 version is fairly broken for me and isn't
maintained as far as I can tell.  I haven't had time/enthusiasm to
debug the things which bit me as I don't understand a lot of the code
these days.  In fact, I'm not sure I understand actually how to use
the most significant new features like the spam-processing and the PGP
support.  I think the documentation and customization support for it
isn't good enough.  I mention this so you're aware of a possible
maintenance issue.

> Dave has write access to Gnus' CVS and often does commits there.

[I think I lost access, but it's definitely a long time since I
committed anything.]

Re: Gnus update

[Lars Magne Ingebrigtsen]

Dave Love <d.love@dl.ac.uk> writes:

> If this is about installing Gnus 5.10 in Emacs , you should be aware
> that significant changes were installed without copyright papers on
> file.  I don't have examples, but larsi complained about it on the
> Gnus list, and I spotted examples subsequently. 

Hm.  I thought everybody were really strict about paperwork ever
since you merged 5.9 into Emacs.  Do you have any examples?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus update

[Ted Zlatanov]

On Fri, 23 Jul 2004, d.love@dl.ac.uk wrote:

> Also, the latest 5.10 version is fairly broken for me and isn't
> maintained as far as I can tell.  I haven't had time/enthusiasm to
> debug the things which bit me as I don't understand a lot of the code
> these days.  

Have you posted about these problems on the Gnus mailing list?  What
do you mean by "isn't maintained"?

> In fact, I'm not sure I understand actually how to use the most
> significant new features like the spam-processing and the PGP
> support.  I think the documentation and customization support for it
> isn't good enough.  

I'll assume you refer to spam processing with "it" above.

I am currently the maintainer of that code, and welcome discussion on
this topic in the Gnus mailing list.  I've had help from many sources
to improve the documentation and the work continues.

Could you please point out specific problems or propose an alternate
documentation layout or customization system, because I just don't
know what "good enough" means?  As far as I know, nothing as complex
and powerful as the Gnus spam processing exists for other MUAs, which
may be part of the problem.

Thanks
Ted

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Juanma Barranquero]

On Fri, 16 Jul 2004 12:08:05 -0400
Richard Stallman <rms@gnu.org> wrote:

> That simplifies matters--what about Stefan and Juanma's changes?

Sure, no problem.  My changes to Gnus are mostly, if not all, of the
typo-fixing variety.

                                                                Juanma

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

    > That simplifies matters--what about Stefan and Juanma's changes?

    Sure, no problem.  My changes to Gnus are mostly, if not all, of the
    typo-fixing variety.

Can you (or someone) put the latest Gnus into a branch in Emacs, and
can you then merge your changes into that branch?

Re: Gnus update

[Reiner Steib]

On Mon, Jul 19 2004, Richard Stallman wrote:

> Can you (or someone) put the latest Gnus into a branch in Emacs, [...]

It should rather be the branch "v5-10" from Gnus CVS.  This branch
contains Gnus 5.10.6 (the latest stable release) plus some bug fixes.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Juanma Barranquero]

On Mon, 19 Jul 2004 14:44:35 -0400
Richard Stallman <rms@gnu.org> wrote:

> Can you (or someone) put the latest Gnus into a branch in Emacs, and
> can you then merge your changes into that branch?

Someone.  I don't use Gnus and I'm not confident enough on my CVS
skills to go branching 'round.

                                                                Juanma

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Andreas Schwab]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On Mon, 19 Jul 2004 14:44:35 -0400
> Richard Stallman <rms@gnu.org> wrote:
>
>> Can you (or someone) put the latest Gnus into a branch in Emacs, and
>> can you then merge your changes into that branch?
>
> Someone.  I don't use Gnus and I'm not confident enough on my CVS
> skills to go branching 'round.

I'm currently in the process of importing the v5_10 branch of the gnus
repository into the gnus-5_10-branch in the emacs repository.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Andreas Schwab]

Andreas Schwab <schwab@suse.de> writes:

> Juanma Barranquero <jmbarranquero@wke.es> writes:
>
>> On Mon, 19 Jul 2004 14:44:35 -0400
>> Richard Stallman <rms@gnu.org> wrote:
>>
>>> Can you (or someone) put the latest Gnus into a branch in Emacs, and
>>> can you then merge your changes into that branch?
>>
>> Someone.  I don't use Gnus and I'm not confident enough on my CVS
>> skills to go branching 'round.
>
> I'm currently in the process of importing the v5_10 branch of the gnus
> repository into the gnus-5_10-branch in the emacs repository.

The files are now checked in.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Juanma Barranquero]

On Thu, 22 Jul 2004 18:48:09 +0200
Andreas Schwab <schwab@suse.de> wrote:

> The files are now checked in.

Great.  Thanks.

                                                                Juanma

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

    I'm currently in the process of importing the v5_10 branch of the gnus
    repository into the gnus-5_10-branch in the emacs repository.

    Andreas.

Thank you.

Juanma and Stefan, can you please merge your important Gnus changes
into that branch, then notify me?  That way, we will get most of the
way towards a merged Gnus.  We would then need someone to identify the
other important changes from the change log, and merge those that
matter into this branch.  Then we could copy this branch into the
trunk.

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Miles Bader]

On Fri, Jul 23, 2004 at 11:01:34PM -0400, Richard Stallman wrote:
> Juanma and Stefan, can you please merge your important Gnus changes
> into that branch, then notify me?

And for god's sake, leave out the @#$! whitespace changes; indeed an
important goal should be to make the changes as _minimal_ as possible, so
that merging them into later gnus branches is simpler.

> That way, we will get most of the way towards a merged Gnus.  We would then
> need someone to identify the other important changes from the change log,
> and merge those that matter into this branch.

Good luck...

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

    > That way, we will get most of the way towards a merged Gnus.  We would then
    > need someone to identify the other important changes from the change log,
    > and merge those that matter into this branch.

    Good luck...

I thought you had already been working on this.  If the three people
who made most of the changes merge their own changes, the remaining
job is surely much smaller, no?

Can't you do that smaller job?

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Juanma Barranquero]

On Fri, 23 Jul 2004 23:38:14 -0400
Miles Bader <miles@gnu.org> wrote:

> And for god's sake, leave out the @#$! whitespace changes;

OK, I'll be careful to not delete trailing whitespace (in the lisp\gnus
files, I mean, not everywhere).  But the best way not to have trailing
whitespace problems is not having trailing whitespace in the first place. 
(Same goes for these #$@!% tabs, incidentally, though that's quite
another fight.)

                                                                Juanma

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Richard Stallman]

When making fixes to remove trailing whitespace in Gnus, let's install
them rather in the Gnus repository, and let them propagate to Emacs
from there.

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Stefan]

> Juanma and Stefan, can you please merge your important Gnus changes
> into that branch, then notify me?  That way, we will get most of the

Sure,


        Stefan

Re: Gnus update (was: MH-E 7.4.4 checked in)

[Stefan Monnier]

> I'm currently in the process of importing the v5_10 branch of the gnus
> repository into the gnus-5_10-branch in the emacs repository.

I know I'm probably stating the obvious, but just to make sure: I hope
you've made it easy to re-check out the same code from the Gnus repository,
so we can easily keep merging in the future.

I.e. I hope that the Gnus repository now has a "gnus-emacs-base" tag of some
sort on the 5.10 branch (especially since the tag I see in the Emacs
repository only says "gnus-5_10-branch" without indicating which part of the
5.10 branch it is, or even the date when it was checked out).


        Stefan

Re: Gnus update

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I.e. I hope that the Gnus repository now has a "gnus-emacs-base" tag of some
> sort on the 5.10 branch

I have no write access to the Gnus repository.

> (especially since the tag I see in the Emacs repository only says
> "gnus-5_10-branch" without indicating which part of the 5.10 branch it
> is, or even the date when it was checked out).

I just used a freshly checked out tree.  But with the timestamp of the
checkin you should be able to exactly reproduce the tree I used (there is
only very few activity on the branch).  I did leave out a few
XEmacs-specific files, though.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update

[Stefan Monnier]

> I just used a freshly checked out tree.  But with the timestamp of the
> checkin you should be able to exactly reproduce the tree I used (there is
> only very few activity on the branch).  I did leave out a few
> XEmacs-specific files, though.

Then the best option is to not install any changes on the gnus-5_10-branch
and use it similarly to a "vendor branch" (i.e. only commit code coming
from the Gnus repository).


        Stefan

Re: Gnus update

[Reiner Steib]

On Mon, Jul 26 2004, Stefan Monnier wrote:

> On Mon, Jul 26 2004, Andreas Schwab wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> I.e. I hope that the Gnus repository now has a "gnus-emacs-base"
>>> tag of some sort on the 5.10 branch
>>
>> I have no write access to the Gnus repository.

I could do this, if someone tells me what exactly has to be done.
(I'm not too familiar with branches and tags.)

Do we also need a tag in the Emacs repository to make merging changes
on that branch back to Gnus easier?

>>> (especially since the tag I see in the Emacs repository only says
>>> "gnus-5_10-branch" without indicating which part of the 5.10 branch it
>>> is, or even the date when it was checked out).
>>
>> I just used a freshly checked out tree.  But with the timestamp of the
>> checkin you should be able to exactly reproduce the tree I used (there is
>> only very few activity on the branch).  I did leave out a few
>> XEmacs-specific files, though.

There have been no changes since your checkout, I think.

> Then the best option is to not install any changes on the gnus-5_10-branch
> and use it similarly to a "vendor branch" (i.e. only commit code coming
> from the Gnus repository).

I don't understand.  Wasn't the purpose of the branch to install yours
and Juanma's changes?  If you install these changes in the
gnus-5_10-branch, I can apply the changes to Gnus' v5-10 branch and to
the trunk too.

Maybe it's more simple to do this via Miles Bader's arch repository
(if I understood Miles correctly).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Andreas Schwab]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Mon, Jul 26 2004, Stefan Monnier wrote:
>
>> On Mon, Jul 26 2004, Andreas Schwab wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>>> I.e. I hope that the Gnus repository now has a "gnus-emacs-base"
>>>> tag of some sort on the 5.10 branch
>>>
>>> I have no write access to the Gnus repository.
>
> I could do this, if someone tells me what exactly has to be done.
> (I'm not too familiar with branches and tags.)

You'll just need to check out the v5-10 branch and run "cvs tag TAGNAME".

> Do we also need a tag in the Emacs repository to make merging changes
> on that branch back to Gnus easier?

Probably a good idea.

> There have been no changes since your checkout, I think.

Yes, but just in case you can use '2004-07-22 16:45 UTC' as the date tag
to get the exact copy I used.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update

[Reiner Steib]

On Tue, Jul 27 2004, Andreas Schwab wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> On Mon, Jul 26 2004, Stefan Monnier wrote:
>>> On Mon, Jul 26 2004, Andreas Schwab wrote:
>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>
>>>>> I.e. I hope that the Gnus repository now has a "gnus-emacs-base"
>>>>> tag of some sort on the 5.10 branch
>>>>
>>>> I have no write access to the Gnus repository.
>>
>> I could do this, if someone tells me what exactly has to be done.
>> (I'm not too familiar with branches and tags.)
>
> You'll just need to check out the v5-10 branch and run "cvs tag TAGNAME".

What should be the TAGNAME?  In Emacs, it is called
"gnus-5_10-branchpoint", so I'd use "emacs21-gnus-5_10-branchpoint"
[1] (or "emacs21_4-gnus-5_10-branchpoint"?).  Lars, it that okay for
you?

Bye, Reiner.

[1] Similar to the existing tag names in Gnus:

,----[ `gnus.el' ]
| [...]
| 	o0-01: 6.26
| 	oO-01: 6.26
| 	v5-8-8: 5.148.2.1
| 	post-merge-emacs21-1: 6.4
| 	pre-merge-emacs21-1: 6.3
| 	V5-8: 5.148.0.2
| 	pre-ognus-point: 5.148
| 	emacs21-branch: 5.143.0.2
| 	emacs21-branch-point: 5.143
| 	v5-8-7: 5.139
| [...]
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> What should be the TAGNAME?  In Emacs, it is called
> "gnus-5_10-branchpoint", so I'd use "emacs21-gnus-5_10-branchpoint"
> [1] (or "emacs21_4-gnus-5_10-branchpoint"?).  Lars, it that okay for
> you?

Yup; sounds good.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus update

[Reiner Steib]

On Mon, Aug 02 2004, Lars Magne Ingebrigtsen wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> What should be the TAGNAME?  In Emacs, it is called
>> "gnus-5_10-branchpoint", so I'd use "emacs21-gnus-5_10-branchpoint"
>> [1] (or "emacs21_4-gnus-5_10-branchpoint"?).  Lars, it that okay for
>> you?
>
> Yup; sounds good.

Done.  "emacs21_4-gnus-5_10-branchpoint".

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Reiner Steib]

On Mon, Jul 26 2004, Andreas Schwab wrote:

> I did leave out a few XEmacs-specific files, though.

It seem to me that there are still some files weren't updated.  Some
time ago I wrote a shell script[1] that puts Oort Gnus into an Emacs
CVS tree.  When I apply it to gnus-5_10-branch, I get the following
differences:

,----[ M-x cvs-update RET ]
| In directory etc:
|               Modified                etc/gnus-pointer.xbm
|               Modified                etc/gnus-pointer.xpm

These have been modified in Oort Gnus.

|               Unknown                 etc/gnus-ref.tex

This is the Gnus Refcard.  To produce DVI and PS, `refcard.tex' and
`gnuslogo-refcard.eps' are required too.

|               Unknown                 etc/gnus.xbm

I don't know if this is required.

|               Modified                etc/gnus.xpm

Modified in Oort Gnus.

| In directory lisp:
| In directory lisp/gnus:
|               Unknown                 lisp/gnus/blink.pbm
|               Unknown                 lisp/gnus/blink.xpm
|               Unknown                 lisp/gnus/braindamaged.xpm
|               Unknown                 lisp/gnus/cry.xpm
|               Unknown                 lisp/gnus/dead.xpm
|               Unknown                 lisp/gnus/evil.xpm
|               Unknown                 lisp/gnus/forced.xpm
|               Unknown                 lisp/gnus/frown.xpm
|               Unknown                 lisp/gnus/grin.xpm
|               Unknown                 lisp/gnus/indifferent.xpm
|               Unknown                 lisp/gnus/reverse-smile.xpm
|               Unknown                 lisp/gnus/sad.pbm
|               Unknown                 lisp/gnus/sad.xpm
|               Unknown                 lisp/gnus/smile.xpm
|               Unknown                 lisp/gnus/wry.xpm

These are files from etc/smilies (required to display graphical
smilies: :-( :-) ;-) :-| :-/ ...; see `smiley-regexp-alist').  I don't
know if all image formats are required.

|               Unknown                 lisp/gnus/time-date.el

The version from calendar/ doesn't have `time-to-number-of-days', but
I can't find any call to `time-to-number-of-days'.

The files tls.el, dig.el, dns.el from Gnus might be of more general
interest.  Maybe they should be placed in net/? 

| In directory man:
|               Modified                man/emacs-mime.texi
|               Modified                man/gnus-faq.texi
|               Modified                man/gnus.texi
|               Modified                man/message.texi

Modified in Oort Gnus.

|               Unknown                 man/pgg.texi
|               Unknown                 man/sieve.texi
`----

New in Oort Gnus.

Other things that need to be done:

* The entries from GNUS-NEWS should be copied to etc/NEWS.
  - Where to put the items?
  - Replace "^**" by ***.  
  - Remove items that aren't relevant for Emacs, e.g.
    "New make.bat for compiling and installing Gnus under MS Windows".

The above and maybe other items have been mentioned in an earlier
discussion[2].  (The discussion started on the Gnus list.  Later it
was Cc-ed to emacs-devel, too.)

Bye, Reiner.

[1] <URL:http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/Gnus-5-11.sh>

[2] <URL: http://thread.gmane.org/gmane.emacs.gnus.general/55650>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Andreas Schwab]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Mon, Jul 26 2004, Andreas Schwab wrote:
>
>> I did leave out a few XEmacs-specific files, though.
>
> It seem to me that there are still some files weren't updated.  Some
> time ago I wrote a shell script[1] that puts Oort Gnus into an Emacs
> CVS tree.  When I apply it to gnus-5_10-branch, I get the following
> differences:

Would you mind cleaning up the remaining differences?  You seem to have
more knowledge of Gnus versions.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gnus update

[Reiner Steib]

On Tue, Jul 27 2004, Andreas Schwab wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
[...]
>> When I apply it to gnus-5_10-branch, I get the following
>> differences:
>
> Would you mind cleaning up the remaining differences?

I'd like to, but I don't have write access to Emacs' repository.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Reiner Steib]

On Tue, Jul 27 2004, Andreas Schwab wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
[...]
>> It seem to me that there are still some files weren't updated.  Some
>> time ago I wrote a shell script[1] that puts Oort Gnus into an Emacs
>> CVS tree.  When I apply it to gnus-5_10-branch, I get the following
>> differences:
>
> Would you mind cleaning up the remaining differences?

I have started to work on this (I have write access now).

Is anyone else using/testing the gnus-5_10-branch?  Any feedback is
welcome.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Reiner Steib]

Hi,

previously, the file GNUS-NEWS has been merged into the Emacs NEWS
file.  For Pterodactyl Gnus (Gnus 5.8/5.9) those changes were about 60
lines.  For Oort Gnus (Gnus 5.10/5.11) GNUS-NEWS has > 400 lines.
Should it be included in etc/NEWS or should we refer to etc/GNUS-NEWS
(similar to MH-E [1]) and/or to the Gnus manual.  The node (info
"(gnus)Oort Gnus") has the same content as GNUS-NEWS.

Bye, Reiner.

[1]
,----[ etc/NEWS ]
| ** MH-E changes.
| 
| Upgraded to MH-E version 7.4.4. There have been major changes since
| version 5.0.2; see MH-E-NEWS for details.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Richard Stallman]

I guess the GNUS news may as well be a separate file
with a note in NEWS pointing to it.

Re: Gnus update

[Reiner Steib]

On Thu, Aug 05 2004, Richard Stallman wrote:

> I guess the GNUS news may as well be a separate file
> with a note in NEWS pointing to it.

I have added etc/GNUS-NEWS and the following text in etc/NEWS:

--8<---------------cut here---------------start------------->8---
** Gnus package

*** Gnus now includes Sieve and PGG
Sieve is a library for managing Sieve scripts.  PGG is a library to handle
PGP/MIME.

*** There are many news features, bug fixes and improvements.
See the file GNUS-NEWS or the node "Oort Gnus" in the Gnus manual for details.
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Per Abrahamsen]

Andreas Schwab <schwab@suse.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I.e. I hope that the Gnus repository now has a "gnus-emacs-base" tag of some
>> sort on the 5.10 branch
>
> I have no write access to the Gnus repository.

I feel pretty sure if you write Lars and ask for it, you will get it.
Especially if you state why (to help with the Emacs merge).

Re: MH-E 7.4.4 checked in

[Richard Stallman]

    Why do we need to merge those changes?

Surely you jest.  We made those changes for reasons.
Maybe some of them are not needed, but surely some are.

Re: MH-E 7.4.4 checked in

[Eli Zaretskii]

> From: Kai Grossjohann <kai@emptydomain.de>
> Date: Wed, 14 Jul 2004 09:38:57 +0200
> 
> What I do with Tramp is that I merge the *.el files into the Emacs
> repository and then, manually, compose ChangeLog entries describing
> the changes.
> 
> So usually the ChangeLog in the Tramp repository might have many
> entries between two releases, whereas the Emacs repository typically
> just has two entries for each release (one for Michael's changes and
> one for my own changes).  The ChangeLog entries in the Emacs
> repository summarize the Tramp entries in such a way that, for
> example, changes made and then reverted are not described (since the
> intermediate version never showed up in the Emacs repository).
> 
> What do people think about this?

I think Miles objected to having such edits in ChangeLog.

Re: MH-E 7.4.4 checked in

[Miles Bader]

On Wed, Jul 14, 2004 at 11:35:35PM +0200, Eli Zaretskii wrote:
> > What do people think about this?
> 
> I think Miles objected to having such edits in ChangeLog.

Note that my objection lies in the way that unconstrained ChangeLog edits
made it harder relate the history of two branches (to the extent that you
need to use ChangeLog to do so -- but a well-maintained ChangeLog is a
valuable tool for this purpose, especially if you're using a
non-changeset-oriented source-control system like CVS).  If Kai's "system"
puts well-defined merge-markers into his synthesized ChangeLogs, so you
pretty much tell which changes came from where, it might also be reasonable.

And of course, Kai seems committed to doing all the merging himself... :-)

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: MH-E 7.4.4 checked in

[Kai Grossjohann]

Miles Bader <miles@gnu.org> writes:

> Note that my objection lies in the way that unconstrained ChangeLog edits
> made it harder relate the history of two branches (to the extent that you
> need to use ChangeLog to do so -- but a well-maintained ChangeLog is a
> valuable tool for this purpose, especially if you're using a
> non-changeset-oriented source-control system like CVS).  If Kai's "system"
> puts well-defined merge-markers into his synthesized ChangeLogs, so you
> pretty much tell which changes came from where, it might also be reasonable.

My goal is to sync each stable release of Tramp with Emacs in such a
way that the two copies are equal.  So a comment along the lines of
"Tramp synced with 2.0.42" is pretty clear, I guess ;-)

So far, only little changes had been made in Emacs CVS, but now, Luc
has written lots of email that I still haven't fully processed...  So
perhaps this approach will prove to be more work than I intended.

But in the case of Gnus, it appears that lots of changes have been
made to Emacs CVS which have not systematically been merged back.  I
wonder if something could be done about this?

Perhaps all Emacs developers working on externally maintained package
X should get CVS access to that package, as well?

Kai

Re: MH-E 7.4.4 checked in

[Luc Teirlinck]

Kai Grossjohann wrote:

   So far, only little changes had been made in Emacs CVS, but now, Luc
   has written lots of email that I still haven't fully processed...  So
   perhaps this approach will prove to be more work than I intended.

I _had_ to make a change in Emacs Tramp CVS because otherwise Tramp
might have malfunctioned after I made my `visited-file-modtime'
change.  I yesterday made the minimal change required to adapt Tramp
to that change.  I do not plan any further changes to the Emacs Tramp
CVS.  I believe that further changes to Tramp are necessary, as I
pointed out in those emails.  However, the involved problems are no
worse than, say, the remaining auto-revert problems we know about.
They are unrelated to the `visited-file-modtime' change.  So their
solution could wait until the next Tramp merge with Emacs.  I was
under the impression that there would still be such a merge before the
21.4 release.

Sincerely,

Luc.

Re: MH-E 7.4.4 checked in

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai Grossjohann wrote:
>
>    So far, only little changes had been made in Emacs CVS, but now, Luc
>    has written lots of email that I still haven't fully processed...  So
>    perhaps this approach will prove to be more work than I intended.
>
> I _had_ to make a change in Emacs Tramp CVS because otherwise Tramp
> might have malfunctioned after I made my `visited-file-modtime'
> change.

I'm thankful that you did make those changes!

I just meant that I claimed to be hard-working, yet in fact I'm
lazy...

Kai

Re: MH-E 7.4.4 checked in

[Richard Stallman]

If there are more changes in Tramp that we would like to have
in the Emacs release, it would be really much better to
merge them in now, rather than waiting.
Unless there is some strong reason for delay.

Re: MH-E 7.4.4 checked in

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> If there are more changes in Tramp that we would like to have
> in the Emacs release, it would be really much better to
> merge them in now, rather than waiting.
> Unless there is some strong reason for delay.

I have now synced Tramp 2.0 (i.e., the stable branch) with the Emacs
repository.

Sorry for the delay.

Kai

Gnus update (was: MH-E 7.4.4 checked in)

[Reiner Steib]

On Thu, Jul 15 2004, Kai Grossjohann wrote:

> But in the case of Gnus, it appears that lots of changes have been
> made to Emacs CVS which have not systematically been merged back.  

Correct.

> I wonder if something could be done about this?
>
> Perhaps all Emacs developers working on externally maintained package
> X should get CVS access to that package, as well?

After Miles started to work on merging Gnus, Lars gave him CVS access
to Gnus.  I see not reason that Lars wouldn't give access to other
Emacs developers as well.

OTOH, it has been discussed on emacs-devel that in the future (after
the release) the current development version of Gnus should be put
into Emacs' CVS trunk.  This should simplify future merging.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus update

[Miles Bader]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
> OTOH, it has been discussed on emacs-devel that in the future (after
> the release) the current development version of Gnus should be put
> into Emacs' CVS trunk.  This should simplify future merging.

Yes, that would be great -- at least mostly; could it get tricky once
release time for Emacs nears though...? Gnus is big enough that it may
not be easy to force into a ready-to-release state.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Gnus update

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> > OTOH, it has been discussed on emacs-devel that in the future
> > (after the release) the current development version of Gnus should
> > be put into Emacs' CVS trunk.  This should simplify future
> > merging.
> 
> Yes, that would be great -- at least mostly; could it get tricky
> once release time for Emacs nears though...? Gnus is big enough that
> it may not be easy to force into a ready-to-release state.

How is this going to be managed?  After all, Gnus also works for
XEmacs.  If it is maintained straight in the Emacs CVS trunk, this
might affect the average stability experienced by XEmacs users.  If
we have just a one-way copy of gnus within Emacs, then we probably
need to make it explicitly read-only in some manner to avoid having
fixes disappear.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Gnus update

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> How is this going to be managed?  After all, Gnus also works for
> XEmacs.  If it is maintained straight in the Emacs CVS trunk, this
> might affect the average stability experienced by XEmacs users.  If
> we have just a one-way copy of gnus within Emacs, then we probably
> need to make it explicitly read-only in some manner to avoid having
> fixes disappear.

I think the best thing might be to have neither, but rather do two-way
merging very frequently.

Since most changes do actually occur in the Gnus tree, this would end up
being "mostly" one-way.  To make it practical, there would probably have
to be some awareness on the part of emacs hackers of the situation
(e.g., some care to not remove xemacs-specific code whereas my
impression is that before this was done freely in the emacs branch of
gnus); perhaps the relative rarity of emacs->gnus changes would
make it not _that_ much an issue.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Gnus update

[Lars Magne Ingebrigtsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I think the best thing might be to have neither, but rather do two-way
> merging very frequently.

Yes.  And, er, people should follow changes applied to Emacs CVS and
see whether they should be applied to Gnus CVS.  One could, for
instance, read the emacs-cvslog mailing list on Gmane.  :-)

It should be pretty easy to score up the articles that deal with
Gnus...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus update

[Stefan]

> Yes.  And, er, people should follow changes applied to Emacs CVS and
> see whether they should be applied to Gnus CVS.  One could, for
> instance, read the emacs-cvslog mailing list on Gmane.  :-)

Wasn't there discussion of setting up the cvsdiff stuff to automatically
mail patches to the respective maintainers?


        Stefan

Re: Gnus update

[Frank Schmitt]

David Kastrup <dak@gnu.org> writes:

> How is this going to be managed?  After all, Gnus also works for
> XEmacs.

My impression is that the number of XEmacs users is rapidly
decreasing. Two years ago, the Emacs vs. XEmacs ratio in my favourite
IRC channel was about 50:50. No it's 100:0. OK, perhaps I shouldn't
generalize from this, but my guess is that in say 2006, nobody will talk
about XEmacs anymore.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Gnus update

[David Kastrup]

Frank Schmitt <ich@Frank-Schmitt.net> writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > How is this going to be managed?  After all, Gnus also works for
> > XEmacs.
> 
> My impression is that the number of XEmacs users is rapidly
> decreasing. Two years ago, the Emacs vs. XEmacs ratio in my
> favourite IRC channel was about 50:50. No it's 100:0. OK, perhaps I
> shouldn't generalize from this, but my guess is that in say 2006,
> nobody will talk about XEmacs anymore.

As long as it is a package philosophy to support different editors,
or even different versions of Emacs itself, one can't disregard the
implications by having both developers with just interest in the
current Emacs versions, as well as developers with interest in more
functionality coordinate their changes.

For example, we have a release cycle of once every few years for Emacs
at the moment.  The development pace of some packages might be quite
different, so that it makes sense making its code available more
often to the public.  If it only runs on current developer Emacsen,
this will suffer.

So the problem rests not only with XEmacs, even though the
compatibility issues there might be larger.  As long as some package
maintainer considers compatibility important, we should try to think
about procedures that avoid making this more complicated than
necessary.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Gnus update

[Adrian Aichner]

Frank Schmitt <ich@Frank-Schmitt.net> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> How is this going to be managed?  After all, Gnus also works for
>> XEmacs.
>
> My impression is that the number of XEmacs users is rapidly
> decreasing. Two years ago, the Emacs vs. XEmacs ratio in my favourite
> IRC channel was about 50:50. No it's 100:0. OK, perhaps I shouldn't

Hi Frank, if your favorite IRC channel is #emacs, then the fluctuation
can be explained by the fact that there now is an #xemacs channel as
well.

> generalize from this, but my guess is that in say 2006, nobody will talk
> about XEmacs anymore.

You might be overly "optimistic".

XEmacs is still getting features added which GNU Emacs is lacking,
along from the long-standing XEmacs package system.

bignums
and
modules
are just two that come to mind.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: MH-E 7.4.4 checked in

[Richard Stallman]

    But in the case of Gnus, it appears that lots of changes have been
    made to Emacs CVS which have not systematically been merged back.  I
    wonder if something could be done about this?

The Gnus maintainers really ought to merge changes in both directions
much more often than has been done lately.  That way, it would
not be a problem.

Re: MH-E 7.4.4 checked in

[Richard Stallman]

    So usually the ChangeLog in the Tramp repository might have many
    entries between two releases, whereas the Emacs repository typically
    just has two entries for each release (one for Michael's changes and
    one for my own changes).  The ChangeLog entries in the Emacs
    repository summarize the Tramp entries in such a way that, for
    example, changes made and then reverted are not described (since the
    intermediate version never showed up in the Emacs repository).

    What do people think about this?

This is the ideal method.

Re: MH-E 7.4.4 checked in

[Bill Wohler]

Kai Grossjohann <kai@emptydomain.de> writes:

> So usually the ChangeLog in the Tramp repository might have many
> entries between two releases, whereas the Emacs repository typically
> just has two entries for each release (one for Michael's changes and
> one for my own changes).  The ChangeLog entries in the Emacs
> repository summarize the Tramp entries in such a way that, for
> example, changes made and then reverted are not described (since the
> intermediate version never showed up in the Emacs repository).
>
> What do people think about this?

It would take days to do this each time I made a release given the
volume in the MH-E ChangeLog, so in practice, it would not get done.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: MH-E 7.4.4 checked in

[Kai Grossjohann]

Bill Wohler <wohler@newt.com> writes:

> Kai Grossjohann <kai@emptydomain.de> writes:
>
>> So usually the ChangeLog in the Tramp repository might have many
>> entries between two releases, whereas the Emacs repository typically
>> just has two entries for each release (one for Michael's changes and
>> one for my own changes).  The ChangeLog entries in the Emacs
>> repository summarize the Tramp entries in such a way that, for
>> example, changes made and then reverted are not described (since the
>> intermediate version never showed up in the Emacs repository).
>>
>> What do people think about this?
>
> It would take days to do this each time I made a release given the
> volume in the MH-E ChangeLog, so in practice, it would not get done.

Yeah, it is much easier to do for a small package, like Tramp.

Kai