Re: MH-E 7.4.4 checked in

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

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

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

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.