542e727017 · matheusbsbs/matheus-bagliano

@@ -22,10 +22,10 @@ If you sent a patch and you did not hear any response from anybody for

22 several days, it could be that your patch was totally uninteresting,

23 but it also is possible that it was simply lost in the noise. Please

24 do not hesitate to send a reminder message in such a case. Messages

25 -getting lost in the noise is a sign that people involved don't have

26 -enough mental/time bandwidth to process them right at the moment, and

27 -it often helps to wait until the list traffic becomes calmer before

28 -sending such a reminder.

25 +getting lost in the noise may be a sign that those who can evaluate

26 +your patch don't have enough mental/time bandwidth to process them

27 +right at the moment, and it often helps to wait until the list traffic

28 +becomes calmer before sending such a reminder.

29

30 The list archive is available at a few public sites:

31

@@ -33,7 +33,7 @@ The list archive is available at a few public sites:

33 http://marc.theaimsgroup.com/?l=git

34 http://www.spinics.net/lists/git/

35

36 -For those who prefer to read it over NNTP (including the maintainer):

36 +For those who prefer to read it over NNTP:

37

38 nntp://news.gmane.org/gmane.comp.version-control.git

39

@@ -45,10 +45,12 @@ gmane is often the easiest to follow by readers, like this:

45 as it also allows people who subscribe to the mailing list as gmane

46 newsgroup to "jump to" the article.

47

48 -Some members of the development community can sometimes also be found

49 -on the #git IRC channel on Freenode. Its log is available at:

48 +Some members of the development community can sometimes be found on

49 +the #git and #git-devel IRC channels on Freenode. Their logs are

50 +available at:

51

52 http://colabti.org/irclogger/irclogger_log/git

53 + http://colabti.org/irclogger/irclogger_log/git-devel

54

55 * Reporting bugs

56

@@ -111,18 +113,26 @@ of git: "master", "maint", "next", and "pu".

113

114 The "master" branch is meant to contain what are very well tested and

115 ready to be used in a production setting. Every now and then, a

114 -"feature release" is cut from the tip of this branch and they

115 -typically are named with three dotted decimal digits. The last such

116 -release was 1.8.2 done on Mar 13, 2013. You can expect that the tip of

117 -the "master" branch is always more stable than any of the released

118 -versions.

116 +"feature release" is cut from the tip of this branch. They used to be

117 +named with three dotted decimal digits (e.g. "1.8.5"), but recently we

118 +switched the versioning scheme and "feature releases" are named with

119 +three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

120 +

121 +The last such release was 1.9.0 done on Feb 14, 2014. You can expect

122 +that the tip of the "master" branch is always more stable than any of

123 +the released versions.

124

125 Whenever a feature release is made, "maint" branch is forked off from

121 -"master" at that point. Obvious, safe and urgent fixes after a feature

122 -release are applied to this branch and maintenance releases are cut from

123 -it. The maintenance releases are named with four dotted decimal, named

124 -after the feature release they are updates to; the last such release was

125 -1.8.1.5. New features never go to this branch. This branch is also

126 +"master" at that point. Obvious, safe and urgent fixes after a

127 +feature release are applied to this branch and maintenance releases

128 +are cut from it. The maintenance releases used to be named with four

129 +dotted decimal, named after the feature release they are updates to

130 +(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature

131 +release). These days, maintenance releases are named by incrementing

132 +the last digit of three-dotted decimal name (e.g. "1.9.1" is the first

133 +maintenance relaese for "1.9.0" series).

134 +

135 +New features never go to the 'maint' branch. This branch is also

136 merged into "master" to propagate the fixes forward as needed.

137

138 A new development does not usually happen on "master". When you send a

@@ -138,10 +148,16 @@ breakage. The "next" branch is where new and exciting things take place. A

148 topic that is in "next" is expected to be polished to perfection before it

149 is merged to "master".

150

141 -The "pu" (proposed updates) branch bundles all the remaining topic branches.

142 -The topics on the branch are not complete, well tested, nor well documented

143 -and need further work. When a topic that was in "pu" proves to be in a

144 -testable shape, it is merged to "next".

151 +The "pu" (proposed updates) branch bundles all the remaining topic

152 +branches the maintainer happens to have. There is no guarantee that

153 +the maintainer has enough bandwidth to pick up any and all topics that

154 +are remotely promising from the list traffic, so please do not read

155 +too much into a topic being on (or not on) the "pu" branch. This

156 +branch is mainly to remind the maintainer that the topics in them may

157 +turn out to be interesting when they are polished, nothing more. The

158 +topics on this branch aren't usually complete, well tested, or well

159 +documented and they need further work. When a topic that was in "pu"

160 +proves to be in a testable shape, it is merged to "next".

161

162 You can run "git log --first-parent master..pu" to see what topics are

163 currently in flight. Sometimes, an idea that looked promising turns out

@@ -156,7 +172,7 @@ Note that being in "next" is not a guarantee to appear in the next

172 release, nor even in any future release. There were cases that topics

173 needed reverting a few commits in them before graduating to "master",

174 or a topic that already was in "next" was reverted from "next" because

159 -fatal flaws were found in it after it was merged.

175 +fatal flaws were found in it after it was merged to "next".

176

177

178 * Other people's trees, trusted lieutenants and credits.

@@ -180,48 +196,3 @@ own authoritative repository and maintainers:

196

197 https://github.com/git-l10n/git-po/

198

183 -I would like to thank everybody who helped to raise git into the current

184 -shape. Especially I would like to thank the git list regulars whose help

185 -I have relied on and expect to continue relying on heavily:

186 -

187 - - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,

188 - René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes

189 - Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,

190 - Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general

191 - design and implementation issues and reviews on the mailing list.

192 -

193 - - Shawn and Nicolas Pitre for helping with packfile design and

194 - implementation issues.

195 -

196 - - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for

197 - cvsserver and cvsimport.

198 -

199 - - Paul Mackerras for gitk.

200 -

201 - - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

202 -

203 - - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

204 -

205 - - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe

206 - Bilotta for maintaining and enhancing gitweb.

207 -

208 - - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang

209 - Xin for volunteering to be the l10n coordinator.

210 -

211 - - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related

212 - Porcelains.

213 -

214 - - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for

215 - documentation (and countless others for proofreading and fixing).

216 -

217 - - Alexandre Julliard for Emacs integration.

218 -

219 - - David Aguilar and Charles Bailey for taking good care of git-mergetool

220 - (and Theodore Ts'o for creating it in the first place) and git-difftool.

221 -

222 - - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others

223 - for their effort to move things forward on the Windows front.

224 -

225 - - People on non-Linux platforms for keeping their eyes on portability;

226 - especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,

227 - Brandon Casey, Jeff King, Alex Riesen and countless others.

MaintNotes: 2014 edition