18 files changed, 417 insertions, 214 deletions

diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage
index 2974eee1792..3d9a275c9d2 100644
--- a/admin/notes/bug-triage
+++ b/admin/notes/bug-triage
@@ -11,7 +11,11 @@ interface via org-mode.
 The goal of this triage is to prune down the list of old bugs, closing
 the ones that are not reproducible on the current release.
 
-  1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the
+  0. To start, check the most relevant bugs blocking a release by
+     calling debbugs-gnu-emacs-release-blocking-reports.  If you want
+     to check this for another Emacs version but the next-to-be-released-one,
+     use the "C-u" prefix.
+  1. After that, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the
      web browser), and accept the default list option of bugs that have severity
      serious, important, or normal.
   2. For each bug, we want to primarily make sure it is still
@@ -20,7 +24,7 @@ the ones that are not reproducible on the current release.
      suggested checklist to follow for handling these bugs, along with
      example replies.  Closing, tagging, etc., are done
      with debbugs control messages, which in debbugs-gnu is initiated
-     with a "C".
+     with a "C" or "E".
      [ ] Read the mail thread for the bug.  Find out if anyone has
          been able to reproduce this on the current release.  If
          someone has been able to, then your work is finished for this
@@ -81,13 +85,13 @@ the ones that are not reproducible on the current release.
 * New bug triage process
 
 The goal of the new bug triage process is similar to the backlog triage process,
-except that the focus is on prioritizing the bug, and making sure it is has
+except that the focus is on prioritizing the bug, and making sure it has
 necessary information for others to act on.
 
 For each new bug, ask the following questions:
 
   1. Is the bug report written in a way to be easy to reproduce (starts from
-     emacs -Q, etc.)?  If not, ask the reporter to try and reproduce it on an
+     "emacs -Q", etc.)?  If not, ask the reporter to try and reproduce it on an
      emacs without customization.
   2. Is the bug report written against the latest emacs?  If not, try to
      reproduce on the latest version, and if it can't be reproduced, ask the
diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index dfca809dc46..deb06f552cc 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -8,9 +8,13 @@ This is 95% of all you will ever need to know.
 
 ** How do I report a bug?
 Use M-x report-emacs-bug, or send mail to bug-gnu-emacs@gnu.org.
-If you want to Cc someone, use an "X-Debbugs-CC" header (or
+If you want to Cc someone, use an "X-Debbugs-Cc" header (or
 pseudo-header, see below) instead.
 
+** How do I read a bug?
+Visit https://debbugs.gnu.org/123 in your web browser or try this in
+Emacs: M-x gnus-read-ephemeral-emacs-bug-group.
+
 ** How do I comment on a bug?
 Reply to a mail on the bug-gnu-emacs list in the normal way.
 Or send a mail to 123@debbugs.gnu.org.
@@ -29,7 +33,7 @@ By mailing commands to control@debbugs.gnu.org.  Place commands at the
 start of the message body, one per line.
 
 severity 123 serious|important|normal|minor|wishlist
-tags 123 moreinfo|unreproducible|wontfix|patch
+tags 123 moreinfo|unreproducible|wontfix|patch|notabug
 
 * More detailed information
 
@@ -53,7 +57,7 @@ i) Your report will be assigned a number and generate an automatic reply.
 ii) Optionally, you can set some database parameters when you first
 report a bug (see "Setting bug parameters" below).
 
-iii) If you want to CC: someone, use X-Debbugs-CC: (note this only
+iii) If you want to Cc someone, use X-Debbugs-Cc: (note this only
 applies to _new_ reports, not followups).
 
 Once your report is filed and assigned a number, it is sent out to the
@@ -64,15 +68,15 @@ quiet@debbugs.gnu.org.
 ** How do I reply to an existing bug report?
 Reply to 123@debbugs.gnu.org, replacing 123 with the number
 of the bug you are interested in.  NB this only sends mail to the
-bug-list, it does NOT send a CC to the original bug submitter.
-So you need to explicitly CC him/her (and anyone else you like).
+bug-list, it does NOT send a Cc to the original bug submitter.
+So you need to explicitly Cc him/her (and anyone else you like).
 (This works the same way as all the Emacs mailing lists.  We generally
 don't assume anyone who posts to a list is subscribed to it, so we
 cc everyone on replies.)
 
 (Many people think the submitter SHOULD be automatically subscribed
 to subsequent discussion, but this does not seem to be implemented.
-See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078
+See https://bugs.debian.org/37078
 See also https://debbugs.gnu.org/5439 )
 
 Do NOT send a separate copy to the bug list address, since this may
@@ -80,7 +84,7 @@ generate a new report.  The only time to send mail to the bug list
 address is to create a new report.
 
 Gnus users can add the following to message-dont-reply-to-names;
-similarly with Rmail and rmail-dont-reply-to-names:
+similarly with Rmail and mail-dont-reply-to-names:
 
 "\\(emacs-pretest-bug\\|bug-gnu-emacs\\|bug-\\(e\\|gnu\\)macs\\)@gnu\\.org\\|\
 \\(submit\\|control\\|owner\\)@debbugs\\.gnu\\.org"
@@ -95,20 +99,23 @@ normal bug reporting.)
 
 ** When reporting a new bug, to send a Cc to another address
 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
-Instead, use "X-Debbugs-CC:".  This ensures the Cc address will get a
+Instead, use "X-Debbugs-Cc:".  This ensures the Cc address(es) will get a
 mail with the bug report number in.  If you do not do this, each reply
 in the subsequent discussion might end up creating a new bug.
 This is annoying.  (So annoying that a form of message-id tracking has
 been implemented to hopefully stop this happening, but it is still
-better to use X-Debbugs-CC.)
+better to use X-Debbugs-Cc.)
+
+If you want to send copies to more than one address, add them
+comma-separated in only one X-Debbugs-Cc line.
 
 Like any X-Debbugs- header, this one can also be specified in the
 pseudo-header (see below), if your mail client does not let you add
 "X-" headers.
 
-If a new report contains X-Debbugs-CC in the input, this is
+If a new report contains X-Debbugs-Cc in the input, this is
 converted to a real Cc header in the output.  (See Bug#1780,5384)
-It is also merged into the Resent-CC header (see below).
+It is also merged into the Resent-Cc header (see below).
 
 ** How does Debbugs send out mails?
 
@@ -117,15 +124,15 @@ header is unchanged.  In new reports only (at present), the To:
 address is altered as follows.  Any "bug-gnu-emacs",
 "emacs-pretest-bug", or "submit@debbugs" address is replaced by
 123@debbugs in the mail that gets sent out.  (This also applies to any
-Cc: header, though you should be using X-Debbugs-CC instead in new
+Cc: header, though you should be using X-Debbugs-Cc instead in new
 reports).  The original header is stored as X-Debbugs-Original-To, if
-it was changed.  Any X-Debbugs-CC is merged into the Cc.
+it was changed.  Any X-Debbugs-Cc is merged into the Cc.
 
 Mails arriving at the bug list have the following Resent-* headers:
 
 Resent-From: person who submitted the bug
 Resent-To:   owner@debbugs.gnu.org
-Resent-CC:   maintainer email address, plus any X-Debbugs-CC: entries
+Resent-Cc:   maintainer email address, plus any X-Debbugs-Cc: entries
 
 The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
 
@@ -148,7 +155,7 @@ Package: emacs
 Version: 23.0.60
 Severity: minor
 
-Remember to fix FOO, as discussed on emacs-devel at http://... .
+Remember to fix FOO, as discussed on emacs-devel at https://... .
 
 ** Not interested in tracker control messages (tags being set, etc)?
 Discard mails matching:
@@ -178,7 +185,7 @@ Basically, reply only to the numbered bug address (and any individual
 people's addresses). Do not send mail direct to bug-gnu-emacs or
 emacs-pretest-bug unless you are reporting a new bug.
 
-** To close bug #123 (for example), send mail
+** To close bug#123 (for example), send mail
 
 To: 123-done@debbugs.gnu.org
 
@@ -236,23 +243,31 @@ The control server ignores anything after the last line above.  So you
 can place control commands at the beginning of a reply to a bug
 report, and Bcc: the control server (note the commands have no effect
 if you just send them to the bug-report number).  Bcc: is better than Cc:
-in case people use Reply-to-All in response.
+in case people use Reply-To-All in response.
+
+For the full documentation of control commands, see
+https://debbugs.gnu.org/server-control.html
 
 Some useful control commands:
 
+*** To close a bug and indicate in what Emacs version it was fixed
+close 123 VERSION
+
+where VERSION is XX.YY numerical version number, like 42.1.
+
 *** To reopen a closed bug:
 reopen 123
 
 *** Bugs can be tagged in various ways (eg wontfix, patch, etc).
 The available tags are:
-patch wontfix moreinfo unreproducible fixed notabug
+patch wontfix moreinfo unreproducible fixed notabug help security confirmed easy
 See https://debbugs.gnu.org/Developer#tags
 The list of tags can be prefixed with +, - or =, meaning to add (the
 default), remove, or reset the tags. E.g.:
 
 tags 123 + wontfix
 
-** URL shortcuts
+*** URL shortcuts
 
 https://debbugs.gnu.org/...
 
@@ -263,9 +278,9 @@ from:submitter@email.address
 severity:severity      # all bugs of given severity
 tag:tag                # all bugs with given tag
 
-** Usertags
+*** Usertags
 
-See <http://wiki.debian.org/bugs.debian.org/usertags>
+See <https://wiki.debian.org/bugs.debian.org/usertags>
 
 "Usertags" are very similar to tags: a set of labels that can be added
 to a bug.  There are two differences between normal tags and user tags:
@@ -275,10 +290,9 @@ limited, predefined set of normal tags are available (see above).
 
 2) A usertag is associated with a specific user.  This is normally
 an email address (with an "@" sign and least 4 characters after the "@"),
-but on debbugs.gnu.org, the definition is less strict - anything with
-5 or more alphanumeric characters will work.  For personal tags,
+but on debbugs.gnu.org, it can also be a package name.  For personal tags,
 using an email address is still recommended.  Please only use the
-"emacs" user, or other short users, for "official" tags.
+"emacs" user for "official" tags.
 
 You set usertags in the same way as tags, by talking to the control server.
 One difference is that you can also specify the associated user.
@@ -292,7 +306,7 @@ a) In a control message:
 user emacs      # or email@example.com
 usertags 1234 any-tag-you-like
 
-This will add a usertag "any-tag-you-like" to bug 1234.  The tag will
+This will add a usertag "any-tag-you-like" to bug#1234.  The tag will
 be associated with the user "emacs".  If you omit the first line,
 the tag will be associated with your email address.
 
@@ -370,7 +384,7 @@ will be assigned proper numbers).
 NB you cannot clone a merged bug.  You'd think that trying to do so
 would just give you an unmerged copy of the specified bug number, but no:
 
-http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474742
+https://bugs.debian.org/474742
 
 You must unmerge, clone, then re-merge.
 
@@ -407,21 +421,21 @@ reassign 1234 emacs
 Note that reassigning clears the list of found versions, even if the
 new packages includes the original one.
 
-** To remove spam from the tracker, move it to the 'spam' pseudo-package:
+*** To remove spam from the tracker, move it to the 'spam' pseudo-package:
 reassign 123 spam
 
 (Should not be necessary any more, now that the input is moderated.)
 
-** To change the title of a bug:
+*** To change the title of a bug:
 retitle 123 Some New Title
 
-** To change the submitter address:
+*** To change the submitter address:
 submitter 123 none@example.com
 
 Note that it does not seem to work to specify "Submitter:" in the
 pseudo-header when first reporting a bug.
 
-** How does archiving work?
+*** How does archiving work?
 You can still send mail to a bug after it is closed.  After 28 days with
 no activity, the bug is archived, at which point no more changes can
 be made.  If you try to send mail to the bug after that (or merge with
@@ -484,7 +498,7 @@ the bug web-pages.
 
 *** Debian stuff
 
-https://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
+https://lists.gnu.org/r/emacs-devel/2009-11/msg00440.html
 
 ** Gnus-specific voodoo
 
@@ -507,8 +521,8 @@ reference, you don't need to read these as a user of the system.
 Getting mail from the Emacs bug list into the tracker requires the
 assistance of sysadmin at gnu.org.  The test tracker set-up was, I
 think, [gnu.org #359140]:
-https://lists.gnu.org/archive/html/savannah-hackers/2008-03/msg00074.html
-https://lists.gnu.org/archive/html/savannah-hackers/2008-04/msg00034.html
+https://lists.gnu.org/r/savannah-hackers/2008-03/msg00074.html
+https://lists.gnu.org/r/savannah-hackers/2008-04/msg00034.html
 
 ** The debbugs.gnu.org setup was handled in [gnu.org #510605].
 There are two pieces (replace AT with @ in the following):
@@ -552,7 +566,7 @@ https://savannah.nongnu.org/projects/listhelper
 
 An "X-Debbugs-Envelope-To" header is used to keep track of where the
 mail was actually bound for:
-https://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01211.html
+https://lists.gnu.org/r/emacs-devel/2009-11/msg01211.html
 
 ** Mailing list recipient/sender filters.
 The following mailman filters are useful to stop messages being
diff --git a/admin/notes/copyright b/admin/notes/copyright
index f4c8b847a57..6f7cb153345 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -1,4 +1,4 @@
-Copyright (C) 2007-2017 Free Software Foundation, Inc.
+Copyright (C) 2007-2022 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
@@ -86,7 +86,7 @@ in a README file in each directory with images. (Legal advice says
 that we need not add notices to each image file individually, if they
 allow for that.). It is recommended to use the word "convert" to
 describe the automatic process of changing an image from one format to
-another (https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00618.html).
+another (https://lists.gnu.org/r/emacs-devel/2007-02/msg00618.html).
 
 
 When installing a file with an "unusual" license (after checking first
@@ -159,10 +159,7 @@ etc/future-bug
 
 etc/letter.pbm,letter.xpm
   - trivial, no notice needed.
-<https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00324.html>
-
-etc/FTP, ORDERS
-  - trivial (at time of writing), no license needed
+<https://lists.gnu.org/r/emacs-devel/2007-02/msg00324.html>
 
 etc/HELLO
   standard notices. Just a note that although the file itself is not
@@ -196,14 +193,14 @@ lib-src/etags.c
   After some investigation in Feb 2007, then to the best of our
   knowledge we believe that the original 1984 Emacs version was based
   on the version in BSD4.2. See for example this 1985 post from Ken Arnold:
-  <http://groups.google.com/group/mod.sources/browse_thread/thread/ffe5c55845a640a9>
+  <https://groups.google.com/group/mod.sources/browse_thread/thread/ffe5c55845a640a9>
     I have received enough requests for the current source to ctags
     to post it. Here is the latest version (what will go out with
     4.3, modulo any bugs fixed during the beta period). It is the
     4.2 ctags with recognition of yacc and lex tags added.
 
   See also a 1984 version of ctags (no copyright) posted to net.sources:
-  <http://groups.google.com/group/net.sources/msg/a21b6c21be12a98d>
+  <https://groups.google.com/group/net.sources/msg/a21b6c21be12a98d>
   Version of etags.c in emacs-16.56 duplicates comment typos.
 
   Accordingly, in Feb 2007 we added a 1984 copyright for the
@@ -214,7 +211,7 @@ lib-src/etags.c
   from a legal point of view.
 
 lisp/cedet/semantic/imenu.el
-  - See https://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00410.html
+  - See https://lists.gnu.org/r/emacs-devel/2010-03/msg00410.html
    in which Eric Ludlam established that the remaining contributions
    from authors other than himself were negligible.
 
@@ -223,7 +220,7 @@ lisp/play/tetris.el
   (2007/1) there is no problem with our use of the name "tetris" or
   the concept.
   rms: "My understanding is that game rules as such are not copyrightable."
-  <https://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00960.html>
+  <https://lists.gnu.org/r/emacs-devel/2007-01/msg00960.html>
   rms: Legal advice is that we are ok and need not worry about this.
 
 
@@ -307,8 +304,8 @@ doc/*/*.texi - All manuals should be under GFDL (but see below), and
 should include a copy of it, so that they can be distributed
 separately. faq.texi has a different license, for some reason no-one
 can remember.
-https://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00583.html
-https://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00618.html
+https://lists.gnu.org/r/emacs-devel/2007-04/msg00583.html
+https://lists.gnu.org/r/emacs-devel/2007-04/msg00618.html
 
 doc/misc/mh-e.texi is dual-licensed (GPL and GFDL) per agreement with
 FSF (reconfirmed by rms Aug 25 2008).  Discussion with
@@ -353,9 +350,7 @@ added or not, rms says (2007-02-25, "oldXmenu issues"):
 insque.c had no copyright notice until 2005. The version of insque.c
 added to Emacs 1992-01-27 is essentially the same as insremque.c added
 to glic three days later by Roland McGrath, with an FSF copyright and
-GPL, but no ChangeLog entry:
-<http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/misc/insremque.c?\
-rev=1.1&cvsroot=glibc>
+GPL, but no ChangeLog entry.
 To the best of his recollection, McGrath (who has a copyright
 assignment) was the author of this file (email from roland at frob.com
 to rms, 2007-02-23, "Where did insque.c come from?"). The FSF
@@ -397,7 +392,7 @@ lisp/term/README
   Accordingly, FSF copyright was added.
 
 src/unexhp9k800.c
-  https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00138.html
+  https://lists.gnu.org/r/emacs-devel/2007-02/msg00138.html
   - briefly removed due to legal uncertainly Jan-Mar 2007. The
   relevant assignment is under "hp9k800" in copyright.list. File was
   written by John V. Morris at HP, and disclaimed by the author and
@@ -406,10 +401,10 @@ src/unexhp9k800.c
 
 lisp/progmodes/python.el
 Dave Love alerted us to a potential legal problem:
-https://lists.gnu.org/archive/html/emacs-pretest-bug/2007-04/msg00459.html
+https://lists.gnu.org/r/emacs-pretest-bug/2007-04/msg00459.html
 
 On consultation with a lawyer, we found there was no problem:
-https://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00466.html
+https://lists.gnu.org/r/emacs-devel/2007-05/msg00466.html
 
 
 ** Issues that are "fixed" for the release of Emacs 22, but we may
@@ -527,7 +522,7 @@ None known.
 The EMACS_22_BASE branch was changed to GPLv3 (or later) 2007/07/25.
 
 Some notes:
-(see https://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01431.html)
+(see https://lists.gnu.org/r/emacs-devel/2007-07/msg01431.html)
 
 1. There are some files in the Emacs tree which are not part of Emacs (eg
 those included from Gnulib). These are all copyright FSF and (at time
diff --git a/admin/notes/documentation b/admin/notes/documentation
index fc9c720bd08..d894175e212 100644
--- a/admin/notes/documentation
+++ b/admin/notes/documentation
@@ -5,7 +5,7 @@ Some documentation tips culled from emacs-devel postings.
 
 ** Manual indices
 
-https://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00400.html
+https://lists.gnu.org/r/emacs-devel/2008-10/msg00400.html
 
 For example, this text:
 
@@ -51,7 +51,7 @@ combine them into a single entry, e.g.:
 
 ** Point is a proper name
 
-https://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00414.html
+https://lists.gnu.org/r/emacs-devel/2008-10/msg00414.html
 
 In Emacs tradition, we treat "point" as a proper name when it refers
 to the current editing location. It should not have an article.
@@ -65,7 +65,7 @@ referring to point, please fix it.
 
 ** Don't use passive verbs
 
-https://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00414.html
+https://lists.gnu.org/r/emacs-devel/2008-10/msg00414.html
 
 Documentation is clearer if it avoids the passive voice whenever
 possible.  For example, rather than saying "Point does not move", say
@@ -80,7 +80,7 @@ often provides important information which makes the text clearer, too.
 
 *** Why Antinews is useful
 
-https://lists.gnu.org/archive/html/emacs-devel/2008-11/msg00893.html
+https://lists.gnu.org/r/emacs-devel/2008-11/msg00893.html
 
 The usefulness of Antinews is to help people who buy the printed
 manual and are still using the previous Emacs version.  That's why we
@@ -91,7 +91,7 @@ Of course, we try to make it amusing as well.
 
 *** Don't mention in Antinews too many features absent in old versions
 
-https://lists.gnu.org/archive/html/emacs-devel/2008-11/msg01054.html
+https://lists.gnu.org/r/emacs-devel/2008-11/msg01054.html
 
 Since the purpose of Antinews is to help people use the previous Emacs
 version, there is usually no need to mention features that are simply
@@ -114,4 +114,4 @@ In those cases, the user might have trouble figuring out how to use
 the old version without some sort of help.
 
 ** To indicate possession, write Emacs's rather than Emacs'.
-https://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00649.html
+https://lists.gnu.org/r/emacs-devel/2012-02/msg00649.html
diff --git a/admin/notes/elpa b/admin/notes/elpa
index ea6c132fe19..1e9e7a9f52b 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -5,17 +5,31 @@ repository named "elpa", hosted on Savannah.  To check it out:
 
   git clone git://git.sv.gnu.org/emacs/elpa
   cd elpa
-  git remote set-url --push origin git+ssh://git.sv.gnu.org/srv/git/emacs/elpa
-  [create task branch for edits, etc.]
+  make setup
 
-Changes to this branch propagate to elpa.gnu.org via a "deployment" script run
-daily.  This script (which is kept in elpa/admin/update-archive.sh) generates
-the content visible at https://elpa.gnu.org/packages.
+That leaves the elpa/packages directory empty; you must check out the
+ones you want.
 
-A new package is released as soon as the "version number" of that package is
-changed.  So you can use 'elpa' to work on a package without fear of releasing
-those changes prematurely.  And once the code is ready, just bump the
-version number to make a new release of the package.
+If you wish to check out all the packages into the packages directory,
+you can run the command:
+
+   make worktrees
+
+You can check out a specific package <pkgname> into the packages
+directory with:
+
+   make packages/<pkgname>
+
+
+Changes to this repository propagate to elpa.gnu.org via a
+"deployment" script run daily.  This script generates the content
+visible at https://elpa.gnu.org/packages.
+
+A new package is released as soon as the "version number" of that
+package is changed.  So you can use 'elpa' to work on a package
+without fear of releasing those changes prematurely.  And once the
+code is ready, just bump the version number to make a new release of
+the package.
 
 It is easy to use the elpa branch to deploy a "local" copy of the
 package archive.  For details, see the README file in the elpa branch.
diff --git a/admin/notes/emba b/admin/notes/emba
new file mode 100644
index 00000000000..4c8c27dfeaa
--- /dev/null
+++ b/admin/notes/emba
@@ -0,0 +1,100 @@
+-*- mode: outline; coding: utf-8 -*-
+
+Copyright (C) 2019-2022 Free Software Foundation, Inc.
+See the end of the file for license conditions.
+
+NOTES FOR EMACS CONTINUOUS BUILD ON EMBA
+
+A continuous build for Emacs can be found at
+<https://emba.gnu.org/emacs/emacs>, a Gitlab instance.  It watches the
+Emacs git repository and starts a pipeline (jobset) if there are new
+changes.  This happens for all Emacs branches which belong to the
+defined workflow (see below).
+
+* Mail notifications
+
+In addition to the web interface, emba can send notifications by email
+when a job fails.  It sends notifications about test status to
+<emacs-buildstatus@gnu.org>.
+
+If you want to receive these notifications, please subscribe at
+<https://lists.gnu.org/mailman/listinfo/emacs-buildstatus>.
+
+Alternatively, these notifications can be read via gmane at
+<nntp+news.gmane.org:gmane.emacs.buildstatus>.
+
+The messages contain a URL to the log file of the failed job, like
+<https://emba.gnu.org/emacs/emacs/-/jobs/739/raw>.
+
+* Emacs jobset
+
+The Emacs jobset is defined in the Emacs source tree, file
+'.gitlab-ci.yml'.  All related files are located in directory
+'test/infra'.  They could be adapted for every Emacs branch, see
+<https://emba.gnu.org/help/ci/yaml/README.md>.
+
+Only branches whose name starts with 'master', 'emacs', 'feature', or
+'fix' are considered.  This is declared in the workflow rules of file
+'test/infra/gitlab-ci.yml'.
+
+A jobset on Gitlab is called a pipeline.  Emacs pipelines run through
+the stages 'build-images', 'platform-images' and 'native-comp-images'
+(create an Emacs instance by 'make bootstrap' with different
+configuration parameters) as well as 'normal', 'platforms' and
+'native-comp' (run respective test jobs based on the produced images).
+
+The jobs for stage 'normal' are contained in the file
+'test/infra/test-jobs.yml'.  This file is generated by calling 'make
+-C test generate-test-jobs' in the Emacs source tree, and the
+resulting file should be pushed to the Emacs git repository afterwards.
+
+Every job runs in a Debian docker container.  It uses the local clone
+of the Emacs git repository to perform a bootstrap and test of Emacs.
+This could happen for several jobs with changed configuration, compile,
+and test parameters.
+
+The 'build-image-*' jobs of the different '*-images' stages run only
+if there are severe changes in the Emacs sources, like in Makefiles
+etc.  Otherwise they are skipped, and the corresponding 'test-*' jobs
+run just 'make -C test ...' in the respective Docker image from a
+previous build run.
+
+Jobs in the 'build-images' and 'normal' stages are triggered by
+changes of respective files in the Emacs git repository.  All other
+jobs run scheduled in a pipeline every 8 hours.
+
+The log files for every test job are kept on the server for a week.
+They can be downloaded from the server, visiting the URL
+<https://emba.gnu.org/emacs/emacs/-/pipelines>, and selecting the job
+in question.
+
+Every pipeline generates a JUnit test report for the respective test
+jobs, which can be inspected on the pipeline web page.  This test
+report counts completed ERT tests, aborted tests are not counted.
+
+* Emba configuration
+
+The emba configuration files are hosted on
+<https://gitlab.com/emacs-ci/emba-ansible>.
+
+* Identifying emba
+
+Lisp packages, Makefiles, scripts, and other software could determine
+whether they run on emba by checking for the environment variable
+EMACS_EMBA_CI.
+
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
diff --git a/admin/notes/font-backend b/admin/notes/font-backend
deleted file mode 100644
index 65c37a483bc..00000000000
--- a/admin/notes/font-backend
+++ /dev/null
@@ -1,69 +0,0 @@
-Copyright (C) 2002-2017 Free Software Foundation, Inc.
-See the end of the file for license conditions.
-
-
-New font handling mechanism with font backend method
-----------------------------------------------------
-
-The new files are:
-        font.h -- header providing font-backend related structures
-                (most important ones are "struct font" and "struct
-                font_driver"), macros, and etc.
-        font.c -- main font handling code.
-        xfont.c -- font-driver on X for X core fonts.
-        ftfont.c -- generic font-driver for FreeType fonts providing
-                device-independent methods of struct font_driver.
-        xftfont.c -- font-driver on X using Xft for FreeType fonts
-                utilizing methods provided by ftfont.c.
-        ftxfont.c -- font-driver on X directly using FreeType fonts
-                utilizing methods provided by ftfont.c.
-        w32font.c -- font driver on w32 using Windows native fonts,
-                corresponding to xfont.c
-        w32uniscribe.c -- font driver on w32, using the uniscribe API
-                to provide complex script support for opentype fonts on
-                Windows 2000 and later, or earlier versions of Windows
-                with uniscribe installed as an add-on.
-
-So we already have codes for X and w32.  For Mac it seems that we need
-these files:
-        atmfont.c -- font-driver on mac using ATM fonts, corresponding
-                to xfont.c
-As BDF fonts are currently used on w32, we may also implement these:
-        bdffont.c -- generic font-driver for BDF fonts, corresponding to
-                ftfont.c
-        bdfw32font.c -- font-driver on w32 using BDF fonts,
-                corresponding to ftxfont.c
-But, as FreeType already supports BDF fonts, if FreeType and
-Fontconfig are also available on w32, what we need may be:
-        ftw32font.c -- font-driver on w32 directly using FreeType fonts
-                utilizing methods provided by ftfont.c.
-
-It may be interesting if Emacs supports a frame buffer directly and
-has these font driver.
-        ftfbfont.c -- font-driver on FB for FreeType fonts.
-        bdffbfont.c -- font-driver on FB for BDF fonts.
-
-Note: The fontset related codes are not yet matured to work well with
-the font backend method.  So, for instance, even if you start Emacs
-as something like this:
-  % emacs -fn tahoma
-Non-ASCII Latin characters will not be displayed by the font "tahoma".
-In such a case, please try this:
-
-(set-fontset-font "fontset-default" 'latin '("tahoma" . "unicode-bmp"))
-
-
-This file is part of GNU Emacs.
-
-GNU Emacs is free software: you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-GNU Emacs is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
diff --git a/admin/notes/git-workflow b/admin/notes/git-workflow
index cb10638af82..265a106bad5 100644
--- a/admin/notes/git-workflow
+++ b/admin/notes/git-workflow
@@ -1,7 +1,3 @@
-(This is a draft.  The method here won't actually work yet, because
-neither git-new-workdir nor merge-changelog are in the Emacs
-distribution yet.)
-
 Setting up and using git for normal, simple bugfixing
 =====================================================
 
@@ -12,22 +8,22 @@ git config --global user.email "fchu@example.com"
 git config --global transfer.fsckObjects true
 
 (See the thread "Recommend these .gitconfig settings for git integrity."
-[https://lists.gnu.org/archive/html/emacs-devel/2016-01/threads.html#01802]
+[https://lists.gnu.org/r/emacs-devel/2016-01/threads.html#01802]
 for more details about why that last line is there.)
 
 Initial setup
 =============
 
 Then we want to clone the repository.  We normally want to have both
-the current master and the emacs-26 branch.
+the current master and (if there is one) the active release branch
+(eg emacs-28).
 
 mkdir ~/emacs
 cd ~/emacs
 git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git master
-(cd master; git config push.default current)
-./master/admin/git-new-workdir master emacs-26
-cd emacs-26
-git checkout emacs-26
+cd master
+git config push.default current
+git worktree add ../emacs-28 emacs-28
 
 You now have both branches conveniently accessible, and you can do
 "git pull" in them once in a while to keep updated.
@@ -57,11 +53,11 @@ you commit your change locally and then send a patch file as a bug report
 as described in ../../CONTRIBUTE.
 
 
-Backporting to emacs-26
-=======================
+Backporting to release branch
+=============================
 
 If you have applied a fix to the master, but then decide that it should
-be applied to the emacs-26 branch, too, then
+be applied to the release branch, too, then
 
 cd ~/emacs/master
 git log
@@ -71,7 +67,7 @@ which will look like
 
 commit 958b768a6534ae6e77a8547a56fc31b46b63710b
 
-cd ~/emacs/emacs-26
+cd ~/emacs/emacs-28
 git cherry-pick -xe 958b768a6534ae6e77a8547a56fc31b46b63710b
 
 and add "Backport:" to the commit string.  Then
@@ -79,17 +75,28 @@ and add "Backport:" to the commit string.  Then
 git push
 
 
-Merging emacs-26 to the master
-==============================
+Reverting on release branch
+===========================
+
+If a commit is made to the release branch, and then it is later
+decided that this change should only be on the master branch, the
+simplest way to handle this is to revert the commit on the release
+branch, and include in the associated log entry "do not merge to master".
+(Otherwise, the reversion may get merged to master, and inadvertently
+clobber the change on master if it has been manually made there.)
+
+
+Merging release branch to the master
+====================================
 
 It is recommended to use the file gitmerge.el in the admin directory
-for merging 'emacs-26' into 'master'.  It will take care of many
+for merging the release branch into 'master'.  It will take care of many
 things which would otherwise have to be done manually, like ignoring
 commits that should not land in master, fixing up ChangeLogs and
 automatically dealing with certain types of conflicts.  If you really
 want to, you can do the merge manually, but then you're on your own.
 If you still choose to do that, make absolutely sure that you *always*
-use the 'merge' command to transport commits from 'emacs-26' to
+use the 'merge' command to transport commits from the release branch to
 'master'.  *Never* use 'cherry-pick'!  If you don't know why, then you
 shouldn't manually do the merge in the first place; just use
 gitmerge.el instead.
@@ -102,11 +109,11 @@ up-to-date by doing a pull.  Then start Emacs with
   emacs -l admin/gitmerge.el -f gitmerge
 
 You'll be asked for the branch to merge, which will default to
-'origin/emacs-26', which you should accept.  Merging a local tracking
+(eg) 'origin/emacs-28', which you should accept.  Merging a local tracking
 branch is discouraged, since it might not be up-to-date, or worse,
 contain commits from you which are not yet pushed upstream.
 
-You will now see the list of commits from 'emacs-26' which are not yet
+You will now see the list of commits from the release branch that are not yet
 merged to 'master'.  You might also see commits that are already
 marked for "skipping", which means that they will be merged with a
 different merge strategy ('ours'), which will effectively ignore the
diff --git a/admin/notes/hydra b/admin/notes/hydra
index a0c46df08e4..0987e7be820 100644
--- a/admin/notes/hydra
+++ b/admin/notes/hydra
@@ -1,6 +1,6 @@
 -*- mode: outline; coding: utf-8 -*-
 
-Copyright (C) 2013-2017 Free Software Foundation, Inc.
+Copyright (C) 2013-2022 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 NOTES FOR EMACS CONTINUOUS BUILD ON HYDRA
@@ -10,8 +10,6 @@ https://hydra.nixos.org/jobset/gnu/emacs-trunk
 
 * It builds Emacs on various platforms.
 Sometimes jobs fail due to hydra problems rather than Emacs problems.
-Eg it seems like the darwin build will never work again.
-https://lists.gnu.org/archive/html/hydra-users/2016-01/msg00000.html
 
 * Mail notifications
 In addition to the web interface, Hydra can send notifications by
@@ -22,6 +20,8 @@ Emacs trunk to emacs-buildstatus@gnu.org.
 If you want to receive these notifications, please subscribe at
 https://lists.gnu.org/mailman/listinfo/emacs-buildstatus
 
+(This feature seems to have been broken for ages.)
+
 * The Emacs jobset consists of the following jobs:
 
 ** The 'tarball' job
diff --git a/admin/notes/multi-tty b/admin/notes/multi-tty
index 0969daf9d07..84bc1b77d4e 100644
--- a/admin/notes/multi-tty
+++ b/admin/notes/multi-tty
@@ -1,6 +1,6 @@
 -*- coding: utf-8; mode: text; -*-
 
-Copyright (C) 2007-2017 Free Software Foundation, Inc.
+Copyright (C) 2007-2022 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 From README.multi-tty in the multi-tty branch.
@@ -171,7 +171,11 @@ preload-emacs "$name" wait
 name="$1"
 waitp="$2"
 screendir="/var/run/screen/S-$USER"
-serverdir="/tmp/emacs$UID"
+if [ "${XDG_RUNTIME_DIR+set}" ]; then
+  serverdir="$XDG_RUNTIME_DIR/emacs"
+else
+  serverdir="${TMPDIR-/tmp}/emacs$UID"
+fi
 emacs=/usr/bin/emacs-multi-tty # Or wherever you installed your multi-tty Emacs
 
 if [ -z "$name" ]; then
@@ -305,7 +309,7 @@ THINGS TO DO
    multidisplay (and don't mind core dumps), you can edit src/config.h
    and define HAVE_GTK_MULTIDISPLAY there by hand.
 
-        http://bugzilla.gnome.org/show_bug.cgi?id=85715
+        https://gitlab.gnome.org/GNOME/gtk/issues/221
 
    Update: Han reports that GTK+ version 2.8.9 almost gets display
    disconnects right.  GTK will probably be fully fixed by the time
@@ -470,7 +474,7 @@ THINGS TO DO
    definition.
 
    Exceptions found so far: x-select-text and
-   x-cut-buffer-or-selection-value.
+   x-selection-value.
 
 ** Have a look at fatal_error_hook.
 
diff --git a/admin/notes/nextstep b/admin/notes/nextstep
index a2e5ce2c9b0..b053294880b 100644
--- a/admin/notes/nextstep
+++ b/admin/notes/nextstep
@@ -65,9 +65,6 @@ functions are:
 Currently ctrl-g is not detected in as many circumstances as other emacsen.
 It is not certain whether this is due to the means of event loop integration,
 or errors of omission in the NS code.  This is an area for improvement.
-Also, see the article here and its containing thread:
-
-http://article.gmane.org/gmane.emacs.devel/92021/match=handling%5fsignal
 
 
 
diff --git a/admin/notes/repo b/admin/notes/repo
index 827d6ed1b98..f6004a97db1 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -11,7 +11,7 @@ install it only on the emacs-24 branch, not on the master as well.
 Installing things manually into more than one branch makes merges more
 difficult.
 
-https://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
+https://lists.gnu.org/r/emacs-devel/2010-03/msg01124.html
 
 The exception is, if you know that the change will be difficult to
 merge to the master (eg because the master code has changed a lot).
@@ -40,7 +40,7 @@ so interim merges are unnecessary.
 Or use shelves; or rebase; or do something else.  See the thread for
 yet another fun excursion into the exciting world of version control.
 
-https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
+https://lists.gnu.org/r/emacs-devel/2010-04/msg00086.html
 
 * Installing changes from gnulib
 
diff --git a/admin/notes/spelling b/admin/notes/spelling
new file mode 100644
index 00000000000..b20f68bf624
--- /dev/null
+++ b/admin/notes/spelling
@@ -0,0 +1,11 @@
+Re "behavior" vs "behaviour", etc.
+
+- GNU Emacs originated in the US.
+
+- If there is a choice between US vs UK spelling for a word
+  for new text (code, docs), choose the US variant.
+
+- It's probably (IMHO --ttn, 2017-10-13) not a high priority to
+  change existing text; use your best judgment (ask if unsure).
+
+- https://lists.gnu.org/r/emacs-devel/2005-06/msg00489.html
diff --git a/admin/notes/tags b/admin/notes/tags
index 16565ea00de..1e2a38347da 100644
--- a/admin/notes/tags
+++ b/admin/notes/tags
@@ -3,7 +3,7 @@ Apparently these date from ye olden days, when tags were common
 to several GNU projects.  So many of them had no relevance to Emacs,
 and hence were removed.  See:
 
-https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00042.html
+https://lists.gnu.org/r/emacs-devel/2012-04/msg00042.html
 
 In the unlikely event that you need them, the removed tags were:
 
diff --git a/admin/notes/unicode b/admin/notes/unicode
index bc7279150a9..014bfb9b0d5 100644
--- a/admin/notes/unicode
+++ b/admin/notes/unicode
@@ -1,6 +1,6 @@
                                             -*-mode: text; coding: utf-8;-*-
 
-Copyright (C) 2002-2017 Free Software Foundation, Inc.
+Copyright (C) 2002-2022 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 Importing a new Unicode Standard version into Emacs
@@ -11,15 +11,38 @@ Emacs uses the following files from the Unicode Character Database
 
   . UnicodeData.txt
   . Blocks.txt
-  . BidiMirroring.txt
   . BidiBrackets.txt
+  . BidiMirroring.txt
   . IVD_Sequences.txt
   . NormalizationTest.txt
+  . PropertyValueAliases.txt
+  . ScriptExtensions.txt
+  . Scripts.txt
   . SpecialCasing.txt
+  . confusables.txt
+  . emoji-data.txt
+  . emoji-zwj-sequences.txt
+  . emoji-sequences.txt
   . BidiCharacterTest.txt
 
-First, the first 7 files need to be copied into admin/unidata/, and
-then Emacs should be rebuilt for them to take effect.  Rebuilding
+Emacs also uses the file emoji-test.txt which should be imported from
+the Unicode's Public/emoji/ directory, and IdnaMappingTable.txt from
+the Public/idna/ directory.
+
+First, the first 14 files, emoji-test.txt and IdnaMappingTable.txt
+need to be copied into admin/unidata/, and the file
+https://www.unicode.org/copyright.html should be copied over
+copyright.html in admin/unidata (some of them might need trailing
+whitespace removed before they can be committed to the Emacs
+repository).
+
+Next, review the assignment of default values of the Bidi Class
+property to blocks in the file extracted/DerivedBidiClass.txt from the
+UCD (search for "unassigned" in that file).  Any changes should be
+reflected in the unidata-gen.el file, where it sets up the default
+values around line 210.
+
+Then Emacs should be rebuilt for them to take effect.  Rebuilding
 Emacs updates several derived files elsewhere in the Emacs source
 tree, mainly in lisp/international/.
 
@@ -28,7 +51,10 @@ files, pay attention to any warning or error messages.  In particular,
 admin/unidata/unidata-gen.el will complain if UnicodeData.txt defines
 new bidirectional attributes of characters, because unidata-gen.el,
 bidi.c and dispextern.h need to be updated in that case; failure to do
-so will cause aborts in redisplay.
+so will cause aborts in redisplay.  unidata-gen.el will also complain
+if the format of the Unicode Copyright notice in copyright.html
+changed in significant ways; in that case, update the regular
+expression in unidata-gen-file used to extract the copyright string.
 
 Next, review the changes in UnicodeData.txt vs the previous version
 used by Emacs.  Any changes, be it introduction of new scripts or
@@ -40,15 +66,23 @@ and see if any changes in admin/unidata/blocks.awk are required.
 
 The setting of char-width-table around line 1200 of characters.el
 should be checked against the latest version of the Unicode file
-EastAsianWidth.txt, and any discrepancies fixed.
+EastAsianWidth.txt, and any discrepancies fixed: double-width
+characters are those marked with W or F in that file.  Zero-width
+characters are not taken from EastAsianWidth.txt, they are those whose
+Unicode General Category property is one of Mn, Me, or Cf, and also
+Hangul jungseong and jongseong characters (a.k.a. "Jamo medial vowels"
+and "Jamo final consonants").
 
 Any new scripts added by UnicodeData.txt will also need updates to
 script-representative-chars defined in fontset.el, and also the list
 of OTF script tags in otf-script-alist, whose source is on this page:
 
-  https://www.microsoft.com/typography/otspec/scripttags.htm
+  https://docs.microsoft.com/en-us/typography/opentype/spec/scripttags
 
 Other databases in fontset.el might also need to be updated as needed.
+One notable place to check is the function setup-default-fontset,
+where new scripts will generally need some addition, most probably to
+the list of "simple" scripts (search for "Simple").
 
 The function 'ucs-names', defined in lisp/international/mule-cmds.el,
 might need to be updated because it knows about used and unused ranges
@@ -65,7 +99,51 @@ regarding failing lines.
 
 The file BidiCharacterTest.txt should be copied to the test suite, and
 if its format has changed, the file biditest.el there should be
-modified to follow suit.
+modified to follow suit.  If there's trailing whitespace in
+BidiCharacterTest.txt, it should be removed before committing the new
+version.
+
+src/macuvs.h is a generated file, but if it has changed as a result
+of the updates, please commit it as well (see
+admin/unidata/Makefile.in for an explanation).
+
+Visit "emoji-data.txt" with the rebuilt Emacs, and check that an
+appropriate font is being used for the emoji (by default Emacs uses
+"Noto Color Emoji").  Running the following command in that buffer
+will give you an idea of which codepoints are not supported by
+whichever font Emacs is using.
+
+(defun check-emoji-coverage (font-name-regexp)
+"Display a buffer containing emoji codepoints for which FONT-NAME is not used.
+This must be run from a buffer in the format of emoji-data.txt.
+FONT-NAME-REGEXP is checked using `string-match'."
+(interactive "MFont Name: ")
+(save-excursion
+(goto-char (point-min))
+(let (res char name ifont)
+  (while (re-search-forward "; Emoji_Presentation [^(]+(\\(.\\)[).]" nil t)
+    (setq char (aref (match-string 1) 0))
+    (setq ifont (car (internal-char-font nil char)))
+    (when ifont
+      (setq name (font-xlfd-name ifont)))
+    (if (or (not ifont) (not (string-match font-name-regexp name)))
+        (setq res (concat (string char) res))))
+  (when res
+    (with-output-to-temp-buffer "*Check-Emoji-Coverage*"
+      (princ (format "Font not matching '%s' was used for the following characters:\n%s"
+                     font-name-regexp (reverse res))))))))
+
+Visit "emoji-zwj-sequences.txt" and "emoji-sequences.txt" with the
+rebuilt Emacs, and check that the sample sequences are composed
+properly.  Also check the Unicode style chart file available at
+https://unicode.org/emoji/charts/emoji-style.txt for any issues
+involving VS-15 and VS-16, if so you may need to update the value
+generated for auto-composition-emoji-eligible-codepoints by
+admin/unidata/emoji-zwj.awk.  Note that your emoji font might not have
+glyphs for the newest codepoints yet.
+
+Finally, etc/NEWS should be updated to announce the support for the
+new Unicode version.
 
 Problems, fixmes and other unicode-related issues
 -------------------------------------------------------------
@@ -85,7 +163,7 @@ regard to completeness.
         code (keymap.c and print.c).
 
  * Rationalize character syntax and its relationship to the Unicode
-   database.  (Applies mainly to symbol an punctuation syntax.)
+   database.  (Applies mainly to symbol and punctuation syntax.)
 
  * Fontset handling and customization needs work.  We want to relate
    fonts to scripts, probably based on the Unicode blocks.  The
@@ -230,36 +308,15 @@ nontrivial changes to the build process.
 
         admin/charsets/mapfiles/cns2ucsdkw.txt
 
- * iso-2022-7bit
-
-     This file switches between CJK charsets, which is not encoded in UTF-8.
+ * iso-2022-jp
 
-        etc/HELLO
-
-     Each of these files contains just one CJK charset, but Emacs
-     currently has no easy way to specify set-charset-priority on a
-     per-file basis, so converting any of these files to UTF-8 might
-     change the file's appearance when viewed by an Emacs that is
-     operating in some other language environment.
+     This contains just one CJK charset, but Emacs currently has no
+     easy way to specify set-charset-priority on a per-file basis, so
+     converting this file to UTF-8 might change the file's appearance
+     when viewed by an Emacs that is operating in some other language
+     environment.
 
         etc/tutorials/TUTORIAL.ja
-        lisp/international/ja-dic-cnv.el
-        lisp/international/ja-dic-utl.el
-        lisp/international/kinsoku.el
-        lisp/international/kkc.el
-        lisp/international/titdic-cnv.el
-        lisp/language/japan-util.el
-        lisp/language/japanese.el
-        lisp/leim/quail/cyril-jis.el
-        lisp/leim/quail/hanja-jis.el
-        lisp/leim/quail/japanese.el
-        lisp/leim/quail/py-punct.el
-        lisp/leim/quail/pypunct-b5.el
-
-     This file contains just Chinese characters, and has same problem.
-     Also, it contains characters that cannot be encoded in UTF-8.
-
-        lisp/international/titdic-cnv.el
 
  * utf-8-emacs
 
@@ -272,6 +329,7 @@ nontrivial changes to the build process.
         lisp/language/tibetan.el
         lisp/leim/quail/ethiopic.el
         lisp/leim/quail/tibetan.el
+        lisp/international/titdic-cnv.el
 
  * binary files
 
diff --git a/admin/notes/versioning b/admin/notes/versioning
index dbd563cdc75..9428dc76710 100644
--- a/admin/notes/versioning
+++ b/admin/notes/versioning
@@ -1,6 +1,6 @@
 GNU EMACS VERSIONING                                   -*- org -*-
 
-Ref: https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html
+Ref: https://lists.gnu.org/r/emacs-devel/2014-09/msg00872.html
 
 Emacs version numbers have the form
 
diff --git a/admin/notes/www b/admin/notes/www
index 8e5bfb68d7a..d1a8f0637ff 100644
--- a/admin/notes/www
+++ b/admin/notes/www
@@ -1,10 +1,33 @@
 -*- outline -*-
 
-Copyright (C) 2013-2017 Free Software Foundation, Inc.
+Copyright (C) 2013-2022 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 NOTES FOR EMACS WWW PAGES
 
+* Access
+
+Anyone with write access to the Emacs code repository has the same
+access to the web pages.  See <https://savannah.gnu.org/cvs/?group=emacs>
+for instructions.  After you commit a change to the CVS repository,
+it normally appears automatically on www.gnu.org within a few minutes.
+The basic procedure is:
+
+Initial checkout:
+cvs -z3 -d:ext:<membername>@cvs.savannah.gnu.org:/web/emacs co emacs
+
+Update from repository:
+cvs up -dP
+
+You can use Emacs's VC mode to commit files without having to worry
+about knowing CVS syntax.  You may find M-x cvs-examine a useful,
+more specialized, alternative to M-x vc-dir.
+
+* Manual pages
+
+The scripts admin/make-manuals, admin/upload-manuals can be used to do
+a complete update of the on-line manual pages (e.g. after a release).
+
 * Renaming pages, redirects
 
 Sometimes you want to move a page to a new location.
@@ -64,6 +87,21 @@ work; see manual/.htaccess in the repository.  You only have to add a
 single redirect for every given external manual, you can redirect
 html_node to hmtl_node and html_mono to html_mono.
 
+* Why CVS?
+
+Savannah supports other VCS, and no-one is especially attached to CVS.
+Rather, CVS is the only supported mechanism for getting the changes
+onto www.gnu.org.  See eg
+https://lists.gnu.org/r/bug-gnulib/2012-12/msg00072.html
+
+* CVS alternatives
+
+To use something other than CVS, convert the web-pages CVS repository
+to the other VCS, then set up a two-way sync between them.
+It needs to be two-way in case eg GNU webmasters make a change to the CVS.
+Ref e.g.
+https://github.com/mikjo/bigitr
+https://lists.gnu.org/r/savannah-hackers-public/2013-04/msg00022.html
 
 
 This file is part of GNU Emacs.
diff --git a/admin/notes/years b/admin/notes/years
index 268ef85c5d4..3df8139f9b9 100644
--- a/admin/notes/years
+++ b/admin/notes/years
@@ -3,7 +3,37 @@ HOW TO MAINTAIN COPYRIGHT YEARS FOR GNU EMACS
 Maintaining copyright years is now very simple: every time a new year
 rolls around, add that year to every FSF (and AIST) copyright notice.
 Do this by running the 'admin/update-copyright' script on a fresh repo
-checkout.  Inspect the results for plausibility, then commit them.
+checkout, redirecting its output to a file, so that you could later
+examine the files that don't have copyright notices.  Inspect the
+results for plausibility, then commit them.
+
+A few known problems with the build-aux/update-copyright script:
+
+  . it doesn't update config.bat, msdos/depfiles.bat,
+    nt/configure.bat, etc/tutorials/TUTORIAL.cn, and
+    etc/tutorials/TUTORIAL.he because the "Copyright" statement begins
+    in these files after a prefix that is more than 5 characters long
+  . it doesn't update etc/tutorials/TUTORIAL.nl and
+    etc/tutorials/TUTORIAL.ro for some reason
+  . it doesn't update the second Copyright notice, the one that gets
+    output into PDF and PS, in etc/refcards/ru-refcard.tex
+  . it doesn't update etc/refcards/gnus-refcard.tex and
+    doc/misc/org.org because their Copyright statements have a
+    non-standard format
+  . several README and XPM files under etc/images/, and also
+    etc/refcards/README, msdos/README, and nt/icons/README aren't
+    updated either
+
+These files need to be updated by hand.
+
+Next, run "M-x set-copyright" from admin.el, which updates several
+copyright notices in the Emacs sources.
+
+You should also run the etags test suite in test/manual/etags/.  It
+will most probably fail because the contents of the test files changes
+due to copyright years update, so you need to move each ETAGS and
+CTAGS file produced by the test runs into the corresponding
+ETAGS.good* and CTAGS.good files, and then commit the new test files.
 
 There's no need to worry about whether an individual file has changed
 in a given year - it's sufficient that Emacs as a whole has changed.
@@ -37,4 +67,4 @@ but should keep the full list in a comment in the source.
  --RMS, 2005-07-13
 
 [1] Note that this includes 2001 - see
-<https://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html>
+<https://lists.gnu.org/r/emacs-pretest-bug/2006-12/msg00119.html>