4:25 p.m.
APPROVE COMMIT 21.5
I'm not sure how this happened, whether it's a side effect of a
Mercurial operation or a careless merge by hand, but please be really
careful to ensure that the release Herald markers are not disturbed
when pushing. It would be nice if the logs were in order of commits
(and there are definitely similar artifacts in several logs), but it's
not such a big deal within a version. It is important that commits
that occur *after* a release do not appear in the logs *before* the
release and vice versa.
diff -r 9dc294ae3004 -r 9f1c9f957073 lisp/ChangeLog
--- a/lisp/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/lisp/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -51,15 +51,15 ＠＠
Removed. Move this to C, so we can use
look_for_coding_system_magic_cookie().
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* help.el (describe-function-1):
Document any command remapping that has been done in this function.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* byte-optimize.el (byte-optimize-letX):
diff -r 9dc294ae3004 -r 9f1c9f957073 man/ChangeLog
--- a/man/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/man/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -17,10 +17,6 ＠＠
Document the new syntax of ## for the symbol with name "" interned
in obarray.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/keymaps.texi (Keymaps):
＠＠ -31,6 +27,10 ＠＠
* lispref/keymaps.texi (Other Keymap Functions):
Document the new command remapping functionality in this file.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-06 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/macros.texi (Expansion):
diff -r 9dc294ae3004 -r 9f1c9f957073 src/ChangeLog
--- a/src/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/src/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -89,10 +89,6 ＠＠
Adopt GNU's ## syntax for the interned symbol with the zero-length
name.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* keymap.c:
＠＠ -128,6 +124,10 ＠＠
* keymap.c (complex_vars_of_keymap):
* lisp.h: New CHECK_COMMAND macro.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* minibuf.c (Ftest_completion):
diff -r 9dc294ae3004 -r 9f1c9f957073 tests/ChangeLog
--- a/tests/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/tests/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -14,15 +14,15 ＠＠
Make sure we can search for character ranges successfully when the
syntax table is dirty.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/keymap-tests.el:
Test the new command remapping functionality.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-12 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/mule-tests.el:
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:05 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I'm not sure how this happened, whether it's a side effect of
a
Mercurial operation or a careless merge by hand, but please be
really careful to ensure that the release Herald markers are not
disturbed when pushing.
I haven't analyzed this particular case but the ChangeLogs are a
problem. They don't mix well with the version control system. For your
own administration you want to add them while your doing the
change. But for the outside world they would better be added at the
moment the change is pushed. Which might be much later.
I have had lots of good use of ChangeLogs before but with mercurial it
might be possible to move over to auto generating the ChangeLogs or
similar? You will miss the detailed description of the change for each
file but you will gain the overall comments for the whole commit that
you now must go over to mercurial to see.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:48 p.m.
Mats Lidell writes:
I have had lots of good use of ChangeLogs before but with mercurial
it might be possible to move over to auto generating the ChangeLogs
or similar?
I'm afraid not. It's not really friendly to tarball testers, and at a
minimum to be helpful to them they shouldn't have to search backward
past the previous release to find a relevant change. Even for me as a
heavy user of VCS history it's often convenient to do C-u M-! hg log
--date >DATE-OF-LAST-RELEASE, and a pretty big PITA if that misses
some relevant commits.
If people find it to be a great burden to ensure that logs immediately
after a commit stay on the right side of each release point (and they
might, if we get active; I don't have much intuition for the
dynamics), we could close the ChangeLogs at that point, and simply ask
all contributors to depend on the VCS history tools.
You will miss the detailed description of the change for each file
but you will gain the overall comments for the whole commit that
you now must go over to mercurial to see.
There's no need to abbreviate the per-file comments in a Mercurial
commit. Didier Verna's Patcher will copy all the logs for a changeset
into the commit message, for example, and it helps to ensure that all
the detail is there. I can't imagine it would be hard to point it at
a dummy ChangeLog that exists only for the duration of creating a
single changeset and commit. Alternatively the add-log family of
functions can probably be adapted independently of Patcher.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:01 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I'm afraid not. It's not really friendly to tarball testers,
and at a
minimum to be helpful to them they shouldn't have to search backward
past the previous release to find a relevant change.
The ChangeLogs could be generated and included when making a tarball
and the time of the push will define if it is before or after the
release.
So you can't miss a relevant commit if you base it on what is in
mercurial. The problem is when you look into the ChangeLogs and look
at the dates there. They might reflect the time when the developer did
the changelog item which could be before the release giving the false
info that it was part of the release.
There's no need to abbreviate the per-file comments in a
Mercurial
commit.
No but it is not supported by mercurial. IMHO it is actually the
changeset that you should comment and not each file. That is one
important point with atomic commits. If the changes to each file have
different purposes they should be part of different changesets.
Didier Verna's Patcher will copy all the logs for a changeset
into the commit message, for example, and it helps to ensure that all
the detail is there.
Yes. Patcher provides excellent support for this and helps you create
those ChangeLogs at commit time. Very useful but to bad that I have
so little luck with it and unfortunately mostly have found it to be in
the way for me. Maybe because I prefer command line tools for doing
the commits or the mercurial mode from within XEmacs.
I do try to follow the style manually and include the ChangeLogs in
the commit message but that is of course error prone as well.
Another weak spot with ChangeLogs is that you can forget to update
them. I often do. Patcher helps here of course but still it is a
manual thing to update these files.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:27 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> I'm afraid not. It's not really friendly to tarball testers, and at a
> minimum to be helpful to them they shouldn't have to search backward
> past the previous release to find a relevant change.
The ChangeLogs could be generated and included when making a tarball
and the time of the push will define if it is before or after the
release.
Unfortunately, it doesn't work that way. The order in which Mercurial
prints logs is determined by the DAG, and under our commit discipline
we have no mainline. So if we regenerate the log, anything can happen
with older releases, and people with new releases can no longer
communicate with people with older ChangeLogs about such things.
If at each release we try to include only commits since the last
release date, we lose all the commits on branches merged more recently
that were committed before that date. With git, I believe I know how
to script this correctly, but AFAIK Mercurial doesn't expose the
needed plumbing. So somebody would need to write and maintain a
plug-in.
So you can't miss a relevant commit if you base it on what is in
mercurial.
True, but that could require looking arbitrarily far back into the DAG
for the actual commit of interest since merge commit logs are
typically just "Merge."
The problem is when you look into the ChangeLogs and look at the
dates there. They might reflect the time when the developer did the
changelog item which could be before the release giving the false
info that it was part of the release.
Right. That's why the linear order of a ChangeLog is so important,
and there is no good, automated way that I know of to reproduce that
just from the VCS history. Put it this why: this is one reason why
Bazaar fans are so proud of their "mainline orientation", and the
associated disciplines they impose on their development process. Git
fans respond (correctly, IMO) that "bisection is better", but that
requires that the user have git.
> There's no need to abbreviate the per-file comments in a
Mercurial
> commit.
No but it is not supported by mercurial. IMHO it is actually the
changeset that you should comment and not each file. That is one
important point with atomic commits. If the changes to each file have
different purposes they should be part of different changesets.
Sure. But as far as I can see, the appropriate style is something
like:
Ensure that wadgets are frobbed before being munged.
Tested and documented (closes #DEADBEEF).
foo.c:
(bar) Move call to frob() before mung().
(mung) New final parameter quux, accounts for status return from
frob().
foo.h:
(mung) Update parameter list to include quux.
blatz.c:
(blatz) Update call to mung() with dummy quux parameter.
Add FIXME.
Yes. Patcher provides excellent support for this and helps you
create
those ChangeLogs at commit time. Very useful but to bad that I have
so little luck with it and unfortunately mostly have found it to be in
the way for me. Maybe because I prefer command line tools for doing
the commits or the mercurial mode from within XEmacs.
Sure. That's why I suggest improving add-log and friends. Log
editing support ought to be a separate mode, called from hooks in
VCS-specific modes and Patcher.
I do try to follow the style manually and include the ChangeLogs in
the commit message but that is of course error prone as well.
Another weak spot with ChangeLogs is that you can forget to update
them. I often do. Patcher helps here of course but still it is a
manual thing to update these files.
Sure, like all bureaucracy they're an annoyance when doing "real
work". Thing is, we don't have a replacement as long as we take
tarball distribution seriously.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:34 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
If at each release we try to include only commits since the last
release date, we lose all the commits on branches merged more
recently that were committed before that date.
I can't recreate this problem but probably I haven't understood the
use case. Could you provide a simple scenario, use case, that
illustrates this?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:58 p.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> If at each release we try to include only commits since the last
> release date, we lose all the commits on branches merged more
> recently that were committed before that date.
I can't recreate this problem but probably I haven't understood the
use case. Could you provide a simple scenario, use case, that
illustrates this?
Consider the following sequence:
Time Mainline Branch
0 A --------- A Create branch at revision A
| |
1 | B Revision adding feature B
| |
... [many commits on mainline]
| |
102 C | Release version C 3 months later
| |
103 | D Revision adding feature D
| /
104 E --------+ Revision merging branch to mainline
Now "hg log --date 102" will list C, D, and E, but not B. This is
bad, because the code for B is not in C, but is in E, and therefore
relevant to debugging E.
That's what worries me, anyway. I think I already mentioned that I
know how to script this in git, but I think in Mercurial it would need
to be a Python plugin.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:11 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Now "hg log --date 102" will list C, D, and E, but not B.
This is
bad, because the code for B is not in C, but is in E, and therefore
relevant to debugging E.
Ouch. Seem to be so. But can ancestors be used instead? How about
this?
hg log -r 'ancestors(tip) and not
ancestors(<insert-relase-version-C3>)'
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:31 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Now "hg log --date 102" will list C, D, and E, but not B. This is
> bad, because the code for B is not in C, but is in E, and therefore
> relevant to debugging E.
Ouch. Seem to be so. But can ancestors be used instead? How about
this?
hg log -r 'ancestors(tip) and not
ancestors(<insert-relase-version-C3>)'
Sure, I believe that gets the right commits, but ChangeLog users don't
have that information. It's not obvious to me that it would generate
readable ChangeLogs if that were used at every release. I suspect
you'd end up with branch commits interleaved by date with trunk
commits as in "hg view".
I think the right answer is going to be to abandon ChangeLog files.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:24 a.m.
Stephen J. Turnbull writes:
Mats Lidell writes:
> hg log -r 'ancestors(tip) and not
ancestors(<insert-relase-version-C3>)'
I think the right answer is going to be to abandon ChangeLog files.
BTW, it would be an easier decision (practically a no-brainer) if
Bitbucket can do the above log for us. If not, maybe somebody could
set up a mirror specifically for such queries.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:06 a.m.
Ar an ceathrú lá is fiche de mí na Nollaig, scríobh Stephen J. Turnbull:
APPROVE COMMIT 21.5
I'm not sure how this happened, whether it's a side effect of a
Mercurial operation or a careless merge by hand, but please be really
careful to ensure that the release Herald markers are not disturbed
when pushing. It would be nice if the logs were in order of commits
(and there are definitely similar artifacts in several logs), but it's
not such a big deal within a version.
It is important that commits that occur *after* a release do not
appear
in the logs *before* the release and vice versa.
Personally I don’t think it is that important, because if we’re going to
have branches that we merge, this will arise all the time (or we will end up
merging huge ChangeLog.GTK files, giving no real useful history in the
VCS for annotation).
I think it’s more important that the annotation of the corresponding part of
the ChangeLog, if we’re going to use ChangeLog files, reflects the changeset
ID of the changes to the code, something that changes like your commit can
break. Your particular commit did not break this, for which thank you!
diff -r 9dc294ae3004 -r 9f1c9f957073 lisp/ChangeLog
--- a/lisp/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/lisp/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -51,15 +51,15 ＠＠
Removed. Move this to C, so we can use
look_for_coding_system_magic_cookie().
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* help.el (describe-function-1):
Document any command remapping that has been done in this function.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* byte-optimize.el (byte-optimize-letX):
diff -r 9dc294ae3004 -r 9f1c9f957073 man/ChangeLog
--- a/man/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/man/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -17,10 +17,6 ＠＠
Document the new syntax of ## for the symbol with name "" interned
in obarray.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/keymaps.texi (Keymaps):
＠＠ -31,6 +27,10 ＠＠
* lispref/keymaps.texi (Other Keymap Functions):
Document the new command remapping functionality in this file.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-06 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/macros.texi (Expansion):
diff -r 9dc294ae3004 -r 9f1c9f957073 src/ChangeLog
--- a/src/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/src/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -89,10 +89,6 ＠＠
Adopt GNU's ## syntax for the interned symbol with the zero-length
name.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* keymap.c:
＠＠ -128,6 +124,10 ＠＠
* keymap.c (complex_vars_of_keymap):
* lisp.h: New CHECK_COMMAND macro.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* minibuf.c (Ftest_completion):
diff -r 9dc294ae3004 -r 9f1c9f957073 tests/ChangeLog
--- a/tests/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/tests/ChangeLog Mon Dec 24 01:07:25 2012 +0900
＠＠ -14,15 +14,15 ＠＠
Make sure we can search for character ranges successfully when the
syntax table is dirty.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/keymap-tests.el:
Test the new command remapping functionality.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-12 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/mule-tests.el:
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4331
days inactive
4352
days old
10 comments
3 participants
participants (3)
-
Aidan Kehoe -
Stephen J. Turnbull -
The XEmacs Package Smoketest