Post 1.6.2 maintnotes updates

Thank new contributors as well.

diff --git a/MaintNotes b/MaintNotes
index bbd45f1898980a8278f59fc1d2988176f25a4d21..893c8054c1898a9d66e806d1fd752522c59c511a 100644 (file)
--- a/MaintNotes
+++ b/MaintNotes
@@ -57,12 +57,12 @@ Their gitweb interfaces are found at:
         http://git.kernel.org/?p=git/git.git
         http://repo.or.cz/w/alt-git.git
 
-There are three branches in git.git repository that are not
-about the source tree of git: "todo", "html" and "man".  The
-first one was meant to contain TODO list for me, but I am not
-good at maintaining such a list and it is not as often updated as
-it could/should be.  It also contains some helper scripts I use
-to maintain git.
+There are three branches in git.git repository that are not about the
+source tree of git: "todo", "html" and "man".  The first one was meant
+to contain TODO list for me, but I am not good at maintaining such a
+list and it is in an abandoned state.  The branch mostly is used to
+keep some helper scripts I use to maintain git and the regular "What's
+in/cooking" messages these days.
 
 The "html" and "man" are autogenerated documentation from the
 tip of the "master" branch; the tip of "html" is extracted to be
@@ -75,8 +75,8 @@ links to documentation of older releases.
 
 The script to maintain these two documentation branches are
 found in "todo" branch as dodoc.sh, if you are interested.  It
-is a good demonstration of how to use an update hook to automate
-a task.
+is a good demonstration of how to use a post-update hook to
+automate a task.
 
 There are four branches in git.git repository that track the
 source tree of git: "master", "maint", "next", and "pu".  I may
@@ -92,7 +92,7 @@ but they are not expected to be anything major, and more
 importantly quickly and trivially fixable.  Every now and
 then, a "feature release" is cut from the tip of this branch and
 they typically are named with three dotted decimal digits.  The
-last such release was 1.6.1 done on Dec 24th 2008.  You
+last such release was 1.6.2 done on Mar 3rd 2009.  You
 can expect that the tip of the "master" branch is always more
 stable than any of the released versions.
 
@@ -101,7 +101,7 @@ from "master" at that point.  Obvious, safe and urgent fixes
 after a feature release are applied to this branch and
 maintenance releases are cut from it.  The maintenance releases
 are named with four dotted decimal, named after the feature
-release they are updates to; the last such release was 1.6.0.6.
+release they are updates to; the last such release was 1.6.1.3.
 New features never go to this branch.  This branch is also
 merged into "master" to propagate the fixes forward.
 
@@ -143,7 +143,7 @@ able to safely track them.
 After a feature release is made from "master", however, "next"
 will be rebuilt from the tip of "master" using the surviving
 topics.  The commit that replaces the tip of the "next" will
-have the identical tree, but it will have different ancestry
+usually have the identical tree, but it will have different ancestry
 from the tip of "master".  An announcement will be made to warn
 people about such a rebasing.
 
@@ -173,24 +173,19 @@ do it with this:
 
 Note that being in "next" is not a guarantee to appear in the
 next release (being in "master" is such a guarantee, unless it
-is later found seriously broken and reverted), or even in any
+is later found seriously broken and reverted), nor even in any
 future release.  There even were cases that topics needed
 reverting a few commits in them before graduating to "master",
 or a topic that already was in "next" were entirely reverted
 from "next" because fatal flaws were found in them later.
 
-Starting from v1.5.0, "master" and "maint" have release notes
-for the next release in Documentation/RelNotes-* files, so that
-I do not have to run around summarizing what happened just
-before the release.
-
 
 * Other people's trees, trusted lieutenants and credits.
 
-Documentation/SubmittingPatches outlines who your changes should
-be sent to.  As described in contrib/README, I would delegate
-fixes and enhancements in contrib/ area to primary contributors
-of them.
+Documentation/SubmittingPatches outlines to whom your proposed
+changes should be sent.  As described in contrib/README, I would
+delegate fixes and enhancements in contrib/ area to the primary
+contributors of them.
 
 Although the following are included in git.git repository, they
 have their own authoritative repository and maintainers:
@@ -211,7 +206,8 @@ relying on heavily:
  - Linus on general design issues.
 
  - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
-   René Scharfe and Jeff King on general implementation issues.
+   René Scharfe, Jeff King and Johannes Sixt on general
+   implementation issues.
 
  - Shawn and Nicolas Pitre on pack issues.
 
@@ -223,18 +219,24 @@ relying on heavily:
 
  - Simon Hausmann on git-p4.
 
- - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.
+ - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta
+   on gitweb.
+
+ - J. Bruce Fields on documentation (and countless others for
+   proofreading and fixing).
+
+ - Alexandre Julliard on Emacs integration.
 
- - J. Bruce Fields on documentaton issues.
+ - Charles Bailey for git-mergetool (and Theodore Ts'o for creating
+   the tool).
 
  - Johannes Schindelin, Johannes Sixt and others for their effort
-   to move things forward on the Windows front.  Most of the fruits
-   from their porting efforts have been merged to the mainline git.git
-   repository in 1.6.0 release.
+   to move things forward on the Windows front.
 
  - People on non-Linux platforms for keeping their eyes on
    portability; especially, Randal Schwartz, Theodore Ts'o,
-   Jason Riedy, Thomas Glanzmann, but countless others as well.
+   Jason Riedy, Thomas Glanzmann, Brandon Casey, but countless
+   others as well.
 
 * This document