Post 1.6.2 maintnotes updates

index bbd45f1898..893c8054c1 100644 --- 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