cc1b258e2a · matheusbsbs/matheus-bagliano

@@ -8,20 +8,20 @@ Abstract: Imagine that git development is racing along as usual, when our friend

8

9 The maintainer's git time is spent on three activities.

10

11 - - Communication (60%)

11 + - Communication (45%)

12

13 Mailing list discussions on general design, fielding user

14 questions, diagnosing bug reports; reviewing, commenting on,

15 suggesting alternatives to, and rejecting patches.

16

17 - - Integration (30%)

17 + - Integration (50%)

18

19 Applying new patches from the contributors while spotting and

20 correcting minor mistakes, shuffling the integration and

21 testing branches, pushing the results out, cutting the

22 releases, and making announcements.

23

24 - - Own development (10%)

24 + - Own development (5%)

25

26 Scratching my own itch and sending proposed patch series out.

27

@@ -35,6 +35,9 @@ The policy.

35 contain bugfixes and enhancements in any area, including

36 functionality, performance and usability, without regression.

37

38 + - One release cycle for a feature release is expected to last for

39 + eight to ten weeks.

40 +

41 - Maintenance releases are numbered as vX.Y.Z.W and are meant

42 to contain only bugfixes for the corresponding vX.Y.Z feature

43 release and earlier maintenance releases vX.Y.Z.V (V < W).

@@ -58,12 +61,15 @@ The policy.

61 - 'pu' branch is used to publish other proposed changes that do

62 not yet pass the criteria set for 'next'.

63

61 - - The tips of 'master', 'maint' and 'next' branches will always

62 - fast-forward, to allow people to build their own

63 - customization on top of them.

64 + - The tips of 'master' and 'maint' branches will not be rewound to

65 + allow people to build their own customization on top of them.

66 + Early in a new development cycle, 'next' is rewound to the tip of

67 + 'master' once, but otherwise it will not be rewound until the end

68 + of the cycle.

69

65 - - Usually 'master' contains all of 'maint', 'next' contains all

66 - of 'master' and 'pu' contains all of 'next'.

70 + - Usually 'master' contains all of 'maint' and 'next' contains all

71 + of 'master'. 'pu' contains all the topics merged to 'next', but

72 + is rebuilt directly on 'master'.

73

74 - The tip of 'master' is meant to be more stable than any

75 tagged releases, and the users are encouraged to follow it.

@@ -76,11 +82,16 @@ The policy.

82 A typical git day for the maintainer implements the above policy

83 by doing the following:

84

79 - - Scan mailing list and #git channel log. Respond with review

80 - comments, suggestions etc. Kibitz. Collect potentially

81 - usable patches from the mailing list. Patches about a single

82 - topic go to one mailbox (I read my mail in Gnus, and type

83 - \C-o to save/append messages in files in mbox format).

85 + - Scan mailing list. Respond with review comments, suggestions

86 + etc. Kibitz. Collect potentially usable patches from the

87 + mailing list. Patches about a single topic go to one mailbox (I

88 + read my mail in Gnus, and type \C-o to save/append messages in

89 + files in mbox format).

90 +

91 + - Write his own patches to address issues raised on the list but

92 + nobody has stepped up solving. Send it out just like other

93 + contributors do, and pick them up just like patches from other

94 + contributors (see above).

95

96 - Review the patches in the saved mailboxes. Edit proposed log

97 message for typofixes and clarifications, and add Acks

@@ -96,40 +107,32 @@ by doing the following:

107 - Obviously correct fixes that pertain to the tip of 'master'

108 are directly applied to 'master'.

109

110 + - Other topics are not handled in this step.

111 +

112 This step is done with "git am".

113

114 $ git checkout master ;# or "git checkout maint"

102 - $ git am -3 -s mailbox

115 + $ git am -sc3 mailbox

116 $ make test

117

105 - - Merge downwards (maint->master):

106 -

107 - $ git checkout master

108 - $ git merge maint

109 - $ make test

118 + In practice, almost no patch directly goes to 'master' or

119 + 'maint'.

120

121 - Review the last issue of "What's cooking" message, review the

112 - topics scheduled for merging upwards (topic->master and

113 - topic->maint), and merge.

122 + topics ready for merging (topic->master and topic->maint). Use

123 + "Meta/cook -w" script (where Meta/ contains a checkout of the

124 + 'todo' branch) to aid this step.

125 +

126 + And perform the merge. Use "Meta/Reintegrate -e" script (see

127 + later) to aid this step.

128 +

129 + $ Meta/cook -w last-issue-of-whats-cooking.mbox

130

131 $ git checkout master ;# or "git checkout maint"

116 - $ git merge ai/topic ;# or "git merge ai/maint-topic"

132 + $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"

133 $ git log -p ORIG_HEAD.. ;# final review

134 $ git diff ORIG_HEAD.. ;# final review

135 $ make test ;# final review

120 - $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"

121 -

122 - - Merge downwards (maint->master) if needed:

123 -

124 - $ git checkout master

125 - $ git merge maint

126 - $ make test

127 -

128 - - Merge downwards (master->next) if needed:

129 -

130 - $ git checkout next

131 - $ git merge master

132 - $ make test

136

137 - Handle the remaining patches:

138

@@ -138,9 +141,9 @@ by doing the following:

141 and not in 'master') is applied to a new topic branch that

142 is forked from the tip of 'master'. This includes both

143 enhancements and unobvious fixes to 'master'. A topic

141 - branch is named as ai/topic where "ai" is typically

142 - author's initial and "topic" is a descriptive name of the

143 - topic (in other words, "what's the series is about").

144 + branch is named as ai/topic where "ai" is two-letter string

145 + named after author's initial and "topic" is a descriptive name

146 + of the topic (in other words, "what's the series is about").

147

148 - An unobvious fix meant for 'maint' is applied to a new

149 topic branch that is forked from the tip of 'maint'. The

@@ -158,7 +161,8 @@ by doing the following:

161

162 The above except the "replacement" are all done with:

163

161 - $ git am -3 -s mailbox

164 + $ git checkout ai/topic ;# or "git checkout -b ai/topic master"

165 + $ git am -sc3 mailbox

166

167 while patch replacement is often done by:

168

@@ -166,93 +170,166 @@ by doing the following:

170

171 then replace some parts with the new patch, and reapplying:

172

173 + $ git checkout ai/topic

174 $ git reset --hard ai/topic~$n

170 - $ git am -3 -s 000*.txt

175 + $ git am -sc3 -s 000*.txt

176

177 The full test suite is always run for 'maint' and 'master'

178 after patch application; for topic branches the tests are run

179 as time permits.

180

176 - - Update "What's cooking" message to review the updates to

177 - existing topics, newly added topics and graduated topics.

181 + - Merge maint to master as needed:

182

179 - This step is helped with Meta/cook script (where Meta/ contains

180 - a checkout of the 'todo' branch).

181 -

182 - - Merge topics to 'next'. For each branch whose tip is not

183 - merged to 'next', one of three things can happen:

183 + $ git checkout master

184 + $ git merge maint

185 + $ make test

186

185 - - The commits are all next-worthy; merge the topic to next:

187 + - Merge master to next as needed:

188

189 $ git checkout next

188 - $ git merge ai/topic ;# or "git merge ai/maint-topic"

190 + $ git merge master

191 $ make test

192

193 + - Review the last issue of "What's cooking" again and see if topics

194 + that are ready to be merged to 'next' are still in good shape

195 + (e.g. has there any new issue identified on the list with the

196 + series?)

197 +

198 + - Prepare 'jch' branch, which is used to represent somewhere

199 + between 'master' and 'pu' and often is slightly ahead of 'next'.

200 +

201 + $ Meta/Reintegrate master..pu >Meta/redo-jch.sh

202 +

203 + The result is a script that lists topics to be merged in order to

204 + rebuild 'pu' as the input to Meta/Reintegrate script. Remove

205 + later topics that should not be in 'jch' yet. Add a line that

206 + consists of '###' before the name of the first topic in the output

207 + that should be in 'jch' but not in 'next' yet.

208 +

209 + - Now we are ready to start merging topics to 'next'. For each

210 + branch whose tip is not merged to 'next', one of three things can

211 + happen:

212 +

213 + - The commits are all next-worthy; merge the topic to next;

214 - The new parts are of mixed quality, but earlier ones are

192 - next-worthy; merge the early parts to next:

215 + next-worthy; merge the early parts to next;

216 + - Nothing is next-worthy; do not do anything.

217 +

218 + This step is aided with Meta/redo-jch.sh script created earlier.

219 + If a topic that was already in 'next' gained a patch, the script

220 + would list it as "ai/topic~1". To include the new patch to the

221 + updated 'next', drop the "~1" part; to keep it excluded, do not

222 + touch the line. If a topic that was not in 'next' should be

223 + merged to 'next', add it at the end of the list. Then:

224 +

225 + $ git checkout -B jch master

226 + $ Meta/redo-jch.sh -c1

227 +

228 + to rebuild the 'jch' branch from scratch. "-c1" tells the script

229 + to stop merging at the '###' line you added earlier.

230 +

231 + At this point, build-test the result. It may reveal semantic

232 + conflicts (e.g. a topic renamed a variable, another added a new

233 + reference to the variable under its old name), in which case

234 + prepare an appropriate merge-fix first (see appendix), and

235 + rebuild the 'jch' branch from scratch, starting at the tip of

236 + 'master'.

237 +

238 + Then do the same to 'next'

239

240 $ git checkout next

195 - $ git merge ai/topic~2 ;# the tip two are dubious

196 - $ make test

241 + $ sh Meta/redo-jch.sh -c1 -e

242

198 - - Nothing is next-worthy; do not do anything.

243 + The "-e" option allows the merge message that comes from the

244 + history of the topic and the comments in the "What's cooking" to

245 + be edited. The resulting tree should match 'jch' as the same set

246 + of topics are merged on 'master'; otherwise there is a mismerge.

247 + Investigate why and do not proceed until the mismerge is found

248 + and rectified.

249

200 - - [** OBSOLETE **] Optionally rebase topics that do not have any commit

201 - in next yet, when they can take advantage of low-level framework

202 - change that is merged to 'master' already.

250 + $ git diff jch next

251

204 - $ git rebase master ai/topic

252 + When all is well, clean up the redo-jch.sh script with

253

206 - This step is helped with Meta/git-topic.perl script to

207 - identify which topic is rebaseable. There also is a

208 - pre-rebase hook to make sure that topics that are already in

209 - 'next' are not rebased beyond the merged commit.

254 + $ sh Meta/redo-jch.sh -u

255

211 - - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'.

256 + This removes topics listed in the script that have already been

257 + merged to 'master'. This unfortunately loses the "###" marker,

258 + so add it again to the appropriate place.

259

213 - $ git checkout pu

214 - $ git reset --hard next

215 - $ git merge ai/topic ;# repeat for all remaining topics

216 - $ make test

260 + - Rebuild 'pu'.

261 +

262 + $ Meta/Reintegrate master..pu >Meta/redo-pu.sh

263 +

264 + Edit the result by adding new topics that are not still in 'pu'

265 + in the script. Then

266 +

267 + $ git checkout -B pu jch

268 + $ sh Meta/redo-pu.sh

269 +

270 + When all is well, clean up the redo-pu.sh script with

271

218 - This step is helped with Meta/PU script

272 + $ sh Meta/redo-pu.sh -u

273

220 - - Push four integration branches to a private repository at

221 - k.org and run "make test" on all of them.

274 + Double check by running

275

223 - - Push four integration branches to /pub/scm/git/git.git at

224 - k.org. This triggers its post-update hook which:

276 + $ git branch --no-merged pu

277

226 - (1) runs "git pull" in $HOME/git-doc/ repository to pull

227 - 'master' just pushed out;

278 + to see there is no unexpected leftover topics.

279

229 - (2) runs "make doc" in $HOME/git-doc/, install the generated

230 - documentation in staging areas, which are separate

231 - repositories that have html and man branches checked

232 - out.

280 + At this point, build-test the result for semantic conflicts, and

281 + if there are, prepare an appropriate merge-fix first (see

282 + appendix), and rebuild the 'pu' branch from scratch, starting at

283 + the tip of 'jch'.

284

234 - (3) runs "git commit" in the staging areas, and run "git

235 - push" back to /pub/scm/git/git.git/ to update the html

236 - and man branches.

285 + - Update "What's cooking" message to review the updates to

286 + existing topics, newly added topics and graduated topics.

287 +

288 + This step is helped with Meta/cook script.

289 +

290 + $ Meta/cook

291 +

292 + This script inspects the history between master..pu, finds tips

293 + of topic branches, compares what it found with the current

294 + contents in Meta/whats-cooking.txt, and updates that file.

295 + Topics not listed in the file but are found in master..pu are

296 + added to the "New topics" section, topics listed in the file that

297 + are no longer found in master..pu are moved to the "Graduated to

298 + master" section, and topics whose commits changed their states

299 + (e.g. used to be only in 'pu', now merged to 'next') are updated

300 + with change markers "<<" and ">>".

301

238 - (4) installs generated documentation to /pub/software/scm/git/docs/

239 - to be viewed from http://www.kernel.org/

302 + Look for lines enclosed in "<<" and ">>"; they hold contents from

303 + old file that are replaced by this integration round. After

304 + verifying them, remove the old part. Review the description for

305 + each topic and update its doneness and plan as needed. To review

306 + the updated plan, run

307

241 - - Fetch html and man branches back from k.org, and push four

242 - integration branches and the two documentation branches to

243 - repo.or.cz and other mirrors.

308 + $ Meta/cook -w

309

310 + which will pick up comments given to the topics, such as "Will

311 + merge to 'next'", etc. (see Meta/cook script to learn what kind

312 + of phrases are supported).

313 +

314 + - Compile, test and install all four (five) integration branches;

315 + Meta/Dothem script may aid this step.

316 +

317 + - Format documentation if the 'master' branch was updated;

318 + Meta/dodoc.sh script may aid this step.

319 +

320 + - Push the integration branches out to public places; Meta/pushall

321 + script may aid this step.

322

323 Some observations to be made.

324

248 - * Each topic is tested individually, and also together with

249 - other topics cooking in 'next'. Until it matures, none part

250 - of it is merged to 'master'.

325 + * Each topic is tested individually, and also together with other

326 + topics cooking first in 'pu', then in 'jch' and then in 'next'.

327 + Until it matures, no part of it is merged to 'master'.

328

329 * A topic already in 'next' can get fixes while still in

330 'next'. Such a topic will have many merges to 'next' (in

331 other words, "git log --first-parent next" will show many

255 - "Merge ai/topic to next" for the same topic.

332 + "Merge branch 'ai/topic' to next" for the same topic.

333

334 * An unobvious fix for 'maint' is cooked in 'next' and then

335 merged to 'master' to make extra sure it is Ok and then

@@ -274,3 +351,78 @@ Some observations to be made.

351 * Being in the 'next' branch is not a guarantee for a topic to

352 be included in the next feature release. Being in the

353 'master' branch typically is.

354 +

355 +

356 +[Appendix]

357 +

358 +Preparing a "merge-fix"

359 +

360 +A merge of two topics may not textually conflict but still have

361 +conflict at the semantic level. A classic example is for one topic

362 +to rename an variable and all its uses, while another topic adds a

363 +new use of the variable under its old name. When these two topics

364 +are merged together, the reference to the variable newly added by

365 +the latter topic will still use the old name in the result.

366 +

367 +The Meta/Reintegrate script that is used by redo-jch and redo-pu

368 +scripts implements a crude but usable way to work this issue around.

369 +When the script merges branch $X, it checks if "refs/merge-fix/$X"

370 +exists, and if so, the effect of it is squashed into the result of

371 +the mechanical merge. In other words,

372 +

373 + $ echo $X | Meta/Reintegrate

374 +

375 +is roughly equivalent to this sequence:

376 +

377 + $ git merge --rerere-autoupdate $X

378 + $ git commit

379 + $ git cherry-pick -n refs/merge-fix/$X

380 + $ git commit --amend

381 +

382 +The goal of this "prepare a merge-fix" step is to come up with a

383 +commit that can be squashed into a result of mechanical merge to

384 +correct semantic conflicts.

385 +

386 +After finding that the result of merging branch "ai/topic" to an

387 +integration branch had such a semantic conflict, say pu~4, check the

388 +problematic merge out on a detached HEAD, edit the working tree to

389 +fix the semantic conflict, and make a separate commit to record the

390 +fix-up:

391 +

392 + $ git checkout pu~4

393 + $ git show -s --pretty=%s ;# double check

394 + Merge branch 'ai/topic' to pu

395 + $ edit

396 + $ git commit -m 'merge-fix/ai/topic' -a

397 +

398 +Then make a reference "refs/merge-fix/ai/topic" to point at this

399 +result:

400 +

401 + $ git update-ref refs/merge-fix/ai/topic HEAD

402 +

403 +Then double check the result by asking Meta/Reintegrate to redo the

404 +merge:

405 +

406 + $ git checkout pu~5 ;# the parent of the problem merge

407 + $ echo ai/topic | Meta/Reintegrate

408 + $ git diff pu~4

409 +

410 +This time, because you prepared refs/merge-fix/ai/topic, the

411 +resulting merge should have been tweaked to include the fix for the

412 +semantic conflict.

413 +

414 +Note that this assumes that the order in which conflicting branches

415 +are merged does not change. If the reason why merging ai/topic

416 +branch needs this merge-fix is because another branch merged earlier

417 +to the integration branch changed the underlying assumption ai/topic

418 +branch made (e.g. ai/topic branch added a site to refer to a

419 +variable, while the other branch renamed that variable and adjusted

420 +existing use sites), and if you changed redo-jch (or redo-pu) script

421 +to merge ai/topic branch before the other branch, then the above

422 +merge-fix should not be applied while merging ai/topic, but should

423 +instead be applied while merging the other branch. You would need

424 +to move the fix to apply to the other branch, perhaps like this:

425 +

426 + $ mf=refs/merge-fix

427 + $ git update-ref $mf/$the_other_branch $mf/ai/topic

428 + $ git update-ref -d $mf/ai/topic

Documentation: update "howto maintain git"