What's cooking (2020/06 #01)
[git.git] / MaintNotes
1 To: git@vger.kernel.org
2 Subject: A note from the maintainer
4 Welcome to the Git development community.
6 This message is written by the maintainer and talks about how Git
7 project is managed, and how you can work with it.
9 * Mailing list and the community
11 The development is primarily done on the Git mailing list. Help
12 requests, feature proposals, bug reports and patches should be sent to
13 the list address <git@vger.kernel.org>.  You don't have to be
14 subscribed to send messages.  The convention on the list is to keep
15 everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
16 I am not subscribed".
18 As an anti-spam measure, the mailing list software rejects messages
19 that are not text/plain and drops them on the floor.  If you are a
20 GMail user, you'd want to make sure "Plain text mode" is checked.
22 Before sending patches, please read Documentation/SubmittingPatches
23 and Documentation/CodingGuidelines to familiarize yourself with the
24 project convention.
26 If you sent a patch and you did not hear any response from anybody for
27 several days, it could be that your patch was totally uninteresting,
28 but it also is possible that it was simply lost in the noise.  Please
29 do not hesitate to send a reminder message in such a case.  Messages
30 getting lost in the noise may be a sign that those who can evaluate
31 your patch don't have enough mental/time bandwidth to process them
32 right at the moment, and it often helps to wait until the list traffic
33 becomes calmer before sending such a reminder.
35 The list archive is available at a few public sites:
37         http://lore.kernel.org/git/
38         http://marc.info/?l=git
39         http://www.spinics.net/lists/git/
41 For those who prefer to read it over NNTP:
43         nntp://nntp.lore.kernel.org/org.kernel.vger.git
44         nntp://news.public-inbox.org/inbox.comp.version-control.git
46 are available.
48 When you point at a message in a mailing list archive, using its
49 message ID is often the most robust (if not very friendly) way to do
50 so, like this:
52         http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
54 Often these web interfaces accept the message ID with enclosing <>
55 stripped (like the above example to point at one of the most important
56 message in the Git list).
58 Some members of the development community can sometimes be found on
59 the #git and #git-devel IRC channels on Freenode.  Their logs are
60 available at:
62         http://colabti.org/irclogger/irclogger_log/git
63         http://colabti.org/irclogger/irclogger_log/git-devel
65 There is a volunteer-run newsletter to serve our community ("Git Rev
66 News" http://git.github.io/rev_news/rev_news.html).
68 Git is a member project of software freedom conservancy, a non-profit
69 organization (https://sfconservancy.org/).  To reach a committee of
70 liaisons to the conservancy, contact them at <git@sfconservancy.org>.
72 For our expectations on the behaviour of the community participants
73 towards each other, see CODE_OF_CONDUCT.md at the top level of the source
74 tree, or:
76     https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
79 * Reporting bugs
81 When you think git does not behave as you expect, please do not stop
82 your bug report with just "git does not work".  "I used git in this
83 way, but it did not work" is not much better, neither is "I used git
84 in this way, and X happend, which is broken".  It often is that git is
85 correct to cause X happen in such a case, and it is your expectation
86 that is broken. People would not know what other result Y you expected
87 to see instead of X, if you left it unsaid.
89 Please remember to always state
91  - what you wanted to achieve;
93  - what you did (the version of git and the command sequence to reproduce
94    the behavior);
96  - what you saw happen (X above);
98  - what you expected to see (Y above); and
100  - how the last two are different.
102 See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
103 hints.
105 If you think you found a security-sensitive issue and want to disclose
106 it to us without announcing it to wider public, please contact us at
107 our security mailing list <git-security@googlegroups.com>.  This is
108 a closed list that is limited to people who need to know early about
109 vulnerabilities, including:
111   - people triaging and fixing reported vulnerabilities
112   - people operating major git hosting sites with many users
113   - people packaging and distributing git to large numbers of people
115 where these issues are discussed without risk of the information
116 leaking out before we're ready to make public announcements.
119 * Repositories and documentation.
121 My public git.git repositories are (mirrored) at:
123   git://git.kernel.org/pub/scm/git/git.git/
124   https://kernel.googlesource.com/pub/scm/git/git
125   git://repo.or.cz/alt-git.git/
126   https://github.com/git/git/
128 This one shows not just the main integration branches, but also
129 individual topics broken out:
131   git://github.com/gitster/git/
133 A few web interfaces are found at:
135   http://git.kernel.org/pub/scm/git/git.git
136   https://kernel.googlesource.com/pub/scm/git/git
137   http://repo.or.cz/w/alt-git.git
139 Preformatted documentation from the tip of the "master" branch can be
140 found in:
142   git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
143   git://repo.or.cz/git-{htmldocs,manpages}.git/
144   https://github.com/gitster/git-{htmldocs,manpages}.git/
146 The manual pages formatted in HTML for the tip of 'master' can be
147 viewed online at:
149   https://git.github.io/htmldocs/git.html
152 * How various branches are used.
154 There are four branches in git.git repository that track the source tree
155 of git: "master", "maint", "next", and "pu".
157 The "master" branch is meant to contain what are very well tested and
158 ready to be used in a production setting.  Every now and then, a
159 "feature release" is cut from the tip of this branch.  They used to be
160 named with three dotted decimal digits (e.g. "1.8.5"), but we have
161 switched the versioning scheme and "feature releases" are named with
162 three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
164 The last such release was 2.27 done on Jun 1st, 2020.  You can expect
165 that the tip of the "master" branch is always more stable than any of
166 the released versions.
168 Whenever a feature release is made, "maint" branch is forked off from
169 "master" at that point.  Obvious and safe fixes after a feature
170 release are applied to this branch and maintenance releases are cut
171 from it.  Usually the fixes are merged to the "master" branch first,
172 several days before merged to the "maint" branch, to reduce the chance
173 of last-minute issues.  The maintenance releases used to be named with
174 four dotted decimal, named after the feature release they are updates
175 to (e.g. "" was the first maintenance release for "1.8.5"
176 feature release).  These days, maintenance releases are named by
177 incrementing the last digit of three-dotted decimal name (e.g. "2.26.1"
178 was the first maintenance release for the "2.26" series).
180 New features never go to the 'maint' branch.  It is merged into "master"
181 primarily to propagate the description in the release notes forward.
183 A new development does not usually happen on "master". When you send a
184 series of patches, after review on the mailing list, a separate topic
185 branch is forked from the tip of "master" (or somewhere older, especially
186 when the topic is about fixing an earlier bug) and your patches are queued
187 there, and kept out of "master" while people test it out. The quality of
188 topic branches are judged primarily by the mailing list discussions.
190 Topic branches that are in good shape are merged to the "next" branch. In
191 general, the "next" branch always contains the tip of "master".  It might
192 not be quite rock-solid, but is expected to work more or less without major
193 breakage. The "next" branch is where new and exciting things take place. A
194 topic that is in "next" is expected to be polished to perfection before it
195 is merged to "master".  Please help this process by building & using the
196 "next" branch for your daily work, and reporting any new bugs you find to
197 the mailing list, before the breakage is merged down to the "master".
199 The "pu" (proposed updates) branch bundles all the remaining topic
200 branches the maintainer happens to have seen.  There is no guarantee that
201 the maintainer has enough bandwidth to pick up any and all topics that
202 are remotely promising from the list traffic, so please do not read
203 too much into a topic being on (or not on) the "pu" branch.  This
204 branch is mainly to remind the maintainer that the topics in them may
205 turn out to be interesting when they are polished, nothing more.  The
206 topics on this branch aren't usually complete, well tested, or well
207 documented and they often need further work.  When a topic that was
208 in "pu" proves to be in a testable shape, it is merged to "next".
210 You can run "git log --first-parent master..pu" to see what topics are
211 currently in flight.  Sometimes, an idea that looked promising turns out
212 to be not so good and the topic can be dropped from "pu" in such a case.
213 The output of the above "git log" talks about a "jch" branch, which is an
214 early part of the "pu" branch; that branch contains all topics that
215 are in "next" and a bit more (but not all of "pu") and is used by the
216 maintainer for his daily work.
218 The two branches "master" and "maint" are never rewound, and "next"
219 usually will not be either.  After a feature release is made from
220 "master", however, "next" will be rebuilt from the tip of "master"
221 using the topics that didn't make the cut in the feature release.
222 Some topics that used to be in "next" during the previous cycle may
223 get ejected from "next" when this happens.
225 A natural consequence of how "next" and "pu" bundles topics together
226 is that until a topic is merged to "next", updates to it is expected
227 by replacing the patch(es) in the topic with an improved version,
228 and once a topic is merged to "next", updates to it needs to come as
229 incremental patches, pointing out what was wrong in the previous
230 patches and how the problem was corrected.
232 Note that being in "next" is not a guarantee to appear in the next
233 release, nor even in any future release.  There were cases that topics
234 needed reverting a few commits in them before graduating to "master",
235 or a topic that already was in "next" was reverted from "next" because
236 fatal flaws were found in it after it was merged to "next".
239 * Other people's trees.
241 Documentation/SubmittingPatches outlines to whom your proposed changes
242 should be sent.  As described in contrib/README, I would delegate fixes
243 and enhancements in contrib/ area to the primary contributors of them.
245 Although the following are included in git.git repository, they have their
246 own authoritative repository and maintainers:
248  - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:
250         https://github.com/prati0100/git-gui.git
252  - gitk-git/ comes from Paul Mackerras's gitk project:
254         git://ozlabs.org/~paulus/gitk
256  - po/ comes from the localization coordinator, Jiang Xin:
258         https://github.com/git-l10n/git-po/
260 When sending proposed updates and fixes to these parts of the system,
261 please base your patches on these trees, not git.git (the former two
262 even have different directory structures).