More information into the README_maintainer file

This commit is contained in:
Carsten Dominik 2010-12-11 17:56:55 +01:00
parent b0844c5e74
commit 561c00930b
2 changed files with 27 additions and 15 deletions

View File

@ -148,12 +148,20 @@ change only this file, use =--only=.
This is still a significant headache. Some hand work is needed here. This is still a significant headache. Some hand work is needed here.
Emacs uses bzr, and while I see all the advantages this would have, I Emacs uses bzr. A useful introduction to bzr for Emacs developers can
cannot bring myself to switch away from git for my day-to-day work. be found [[http://www.emacswiki.org/emacs/BzrForEmacsDevs][here]]. While I see all the advantages this would have, I
cannot bring myself to switch away from git for my day-to-day work,
because I know git so well, and because git seems to me as being much
more powerful, conceptionally simple (once you have [[http://www.newartisans.com/2008/04/git-from-the-bottom-up.html][bent your head
around it]]), and so much faster.
So the way I have been doing things with Emacs is this: So the way I have been doing things with Emacs is this:
1. I do not update the version in Emacs too often. Just once every 1. I do not update the version in Emacs too often. Just once every
few month - this is frequently enough for the Emacs release cycle. few month - this is frequently enough for the Emacs release cycle.
Care must be taken to get in a *new and stable* version shortly
before Emacs goes into feature freeze and pretest, because that
version is going to be in the wild for a long time.
2. I watch the Emacs diffs for changes made by the maintainers of 2. I watch the Emacs diffs for changes made by the maintainers of
Emacs in the org-mode files in Emacs. Any changes that come up Emacs in the org-mode files in Emacs. Any changes that come up
@ -167,9 +175,10 @@ So the way I have been doing things with Emacs is this:
3. When I have made a release (usually I wait for the minor releases 3. When I have made a release (usually I wait for the minor releases
to stabilize), I *copy* org files into the Emacs repository. Yes, to stabilize), I *copy* org files into the Emacs repository. Yes,
I do not merge, I copy. This has been the source of some problems I do not merge, I copy. This has been the source of some problems
in the past - but I have not had the patience to work out a better in the past - Emacs developers are not happy when I accidentally
mechanism, and I really dislike the idea that the version in Emacs overwrite changes they made. But I have not had the patience to
starts diverging from my own. work out a better mechanism, and I really dislike the idea that the
version in Emacs starts diverging from my own.
Careful: Copy /org.texi/ and /orgcard.tex/ into the right places, Careful: Copy /org.texi/ and /orgcard.tex/ into the right places,
and also copy the lisp files with *two exceptions*: Do *not* copy and also copy the lisp files with *two exceptions*: Do *not* copy
@ -197,14 +206,18 @@ So the way I have been doing things with Emacs is this:
When you run the =make_emacs_changelog= program, you will be When you run the =make_emacs_changelog= program, you will be
prompted for a date in ISO format YYYY-MM-DD, this date will be prompted for a date in ISO format YYYY-MM-DD, this date will be
used in the ChangeLog entries - Emacs wants these dates to be the used in the ChangeLog entries - Emacs developers want these dates
time when the change has been installed into Emacs, not the time to be the time when the change has been installed into Emacs, not
when we made the change in our own repository. You will also be the time when we made the change in our own repository. So all the
ChangeLog entries will get the same date. You will also be
prompted for the kind of ChangeLog you want to make, possible prompted for the kind of ChangeLog you want to make, possible
answers are =lisp=, =texi=, and =card=. The program will then answers are =lisp=, =texi=, and =card=. The program will then
select the correct entries for the specified ChangeLog file. If select the correct entries for the specified ChangeLog file. If
you don't like being prompted, you can give the date and type as you don't like being prompted, you can give the date and type as
second and third command line arguments to =make_emacs_changelog=. second and third command line arguments to =make_emacs_changelog=,
for example
: UTILITIES/make_emacs_changelog release_7.02.05..release_7.03.02 2010-12-11 lisp
These entries need to be added to the ChangeLog files in Emacs. These entries need to be added to the ChangeLog files in Emacs.
You should, in the ChangeLog file, select the inserted region of You should, in the ChangeLog file, select the inserted region of
@ -217,8 +230,6 @@ So the way I have been doing things with Emacs is this:
developers often look throught the commit and make minor changes - developers often look throught the commit and make minor changes -
these need to be merged back into our own repo. these need to be merged back into our own repo.
* Updating the list of hooks on Worg * Updating the list of hooks on Worg
The file org-configs/org-hooks.org contains a list of all hooks in The file org-configs/org-hooks.org contains a list of all hooks in

View File

@ -20,10 +20,11 @@ if (!$kind) {
$kind = <>; $kind = <>;
$kind =~ s/\s*(.*?)\s+/$1/; $kind =~ s/\s*(.*?)\s+/$1/;
$kind =~ s/"(.*?)"/$1/; $kind =~ s/"(.*?)"/$1/;
if ($kind ne "lisp" and $kind ne "texi" and $kind ne "card" }
and $kind ne "") {
die "Invalid Changelog kind"; if ($kind ne "lisp" and $kind ne "texi" and $kind ne "card"
} and $kind ne "") {
die "Invalid Changelog kind";
} }
# Run git log to get the commits the messages # Run git log to get the commits the messages