]> git.ipfire.org Git - thirdparty/git.git/commitdiff
MaintNotes: adjust for pinbox->lore, mention CoC
authorJunio C Hamano <gitster@pobox.com>
Mon, 1 Jun 2020 16:31:35 +0000 (09:31 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 1 Jun 2020 16:31:35 +0000 (09:31 -0700)
MaintNotes

index f9510394c796cf4828cb69cbef65c2ac7cb31186..8bbb7a1387afa238561d4bac5aa6df6b12f04fd3 100644 (file)
@@ -34,14 +34,14 @@ becomes calmer before sending such a reminder.
 
 The list archive is available at a few public sites:
 
-        http://public-inbox.org/git/
+        http://lore.kernel.org/git/
         http://marc.info/?l=git
         http://www.spinics.net/lists/git/
 
 For those who prefer to read it over NNTP:
 
+       nntp://nntp.lore.kernel.org/org.kernel.vger.git
         nntp://news.public-inbox.org/inbox.comp.version-control.git
-       nntp://news.gmane.org/gmane.comp.version-control.git
 
 are available.
 
@@ -49,7 +49,7 @@ When you point at a message in a mailing list archive, using its
 message ID is often the most robust (if not very friendly) way to do
 so, like this:
 
-       http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
+       http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
 
 Often these web interfaces accept the message ID with enclosing <>
 stripped (like the above example to point at one of the most important
@@ -69,6 +69,12 @@ Git is a member project of software freedom conservancy, a non-profit
 organization (https://sfconservancy.org/).  To reach a committee of
 liaisons to the conservancy, contact them at <git@sfconservancy.org>.
 
+For our expectations on the behaviour of the community participants
+towards each other, see CODE_OF_CONDUCT.md at the top level of the source
+tree, or:
+
+    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
+
 
 * Reporting bugs
 
@@ -118,7 +124,6 @@ My public git.git repositories are (mirrored) at:
   https://kernel.googlesource.com/pub/scm/git/git
   git://repo.or.cz/alt-git.git/
   https://github.com/git/git/
-  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
 
 This one shows not just the main integration branches, but also
 individual topics broken out:
@@ -127,7 +132,7 @@ individual topics broken out:
 
 A few web interfaces are found at:
 
-  http://git.kernel.org/cgit/git/git.git
+  http://git.kernel.org/pub/scm/git/git.git
   https://kernel.googlesource.com/pub/scm/git/git
   http://repo.or.cz/w/alt-git.git
 
@@ -152,11 +157,11 @@ of git: "master", "maint", "next", and "pu".
 The "master" branch is meant to contain what are very well tested and
 ready to be used in a production setting.  Every now and then, a
 "feature release" is cut from the tip of this branch.  They used to be
-named with three dotted decimal digits (e.g. "1.8.5"), but recently we
+named with three dotted decimal digits (e.g. "1.8.5"), but we have
 switched the versioning scheme and "feature releases" are named with
 three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
 
-The last such release was 2.15 done on Oct 30th, 2017.  You can expect
+The last such release was 2.27 done on Jun 1st, 2020.  You can expect
 that the tip of the "master" branch is always more stable than any of
 the released versions.
 
@@ -169,8 +174,8 @@ of last-minute issues.  The maintenance releases used to be named with
 four dotted decimal, named after the feature release they are updates
 to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
 feature release).  These days, maintenance releases are named by
-incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
-was the first maintenance release for the "2.12" series).
+incrementing the last digit of three-dotted decimal name (e.g. "2.26.1"
+was the first maintenance release for the "2.26" series).
 
 New features never go to the 'maint' branch.  It is merged into "master"
 primarily to propagate the description in the release notes forward.
@@ -214,6 +219,8 @@ The two branches "master" and "maint" are never rewound, and "next"
 usually will not be either.  After a feature release is made from
 "master", however, "next" will be rebuilt from the tip of "master"
 using the topics that didn't make the cut in the feature release.
+Some topics that used to be in "next" during the previous cycle may
+get ejected from "next" when this happens.
 
 A natural consequence of how "next" and "pu" bundles topics together
 is that until a topic is merged to "next", updates to it is expected