735
735
< body class ="article ">
736
736
< div id ="header ">
737
737
< h1 > Submitting Patches</ h1 >
738
- < span id ="revdate "> 2024-05-16 </ span >
738
+ < span id ="revdate "> 2024-05-23 </ span >
739
739
</ div >
740
740
< div id ="content ">
741
741
< div class ="sect1 ">
@@ -745,6 +745,91 @@ <h2 id="_guidelines">Guidelines</h2>
745
745
project. There is also a < a href ="MyFirstContribution.html "> step-by-step tutorial</ a >
746
746
available which covers many of these same guidelines.</ p > </ div >
747
747
< div class ="sect2 ">
748
+ < h3 id ="patch-flow "> A typical life cycle of a patch series</ h3 >
749
+ < div class ="paragraph "> < p > To help us understand the reason behind various guidelines given later
750
+ in the document, first let’s understand how the life cycle of a
751
+ typical patch series for this project goes.</ p > </ div >
752
+ < div class ="olist arabic "> < ol class ="arabic ">
753
+ < li >
754
+ < p >
755
+ You come up with an itch. You code it up. You do not need any
756
+ pre-authorization from the project to do so.
757
+ </ p >
758
+ < div class ="paragraph "> < p > Your patches will be reviewed by other contributors on the mailing
759
+ list, and the reviews will be done to assess the merit of various
760
+ things, like the general idea behind your patch (including "is it
761
+ solving a problem worth solving in the first place?"), the reason
762
+ behind the design of the solution, and the actual implementation.
763
+ The guidelines given here are there to help your patches by making
764
+ them easier to understand by the reviewers.</ p > </ div >
765
+ </ li >
766
+ < li >
767
+ < p >
768
+ You send the patches to the list and cc people who may need to know
769
+ about the change. Your goal is < strong > not</ strong > necessarily to convince others
770
+ that what you are building is good. Your goal is to get help in
771
+ coming up with a solution for the "itch" that is better than what
772
+ you can build alone.
773
+ </ p >
774
+ < div class ="paragraph "> < p > The people who may need to know are the ones who worked on the code
775
+ you are touching. These people happen to be the ones who are
776
+ most likely to be knowledgeable enough to help you, but
777
+ they have no obligation to help you (i.e. you ask them for help,
778
+ you don’t demand). < code > git log -p -- < em > $area_you_are_modifying</ em > </ code > would
779
+ help you find out who they are.</ p > </ div >
780
+ </ li >
781
+ < li >
782
+ < p >
783
+ You get comments and suggestions for improvements. You may even get
784
+ them in an "on top of your change" patch form. You are expected to
785
+ respond to them with "Reply-All" on the mailing list, while taking
786
+ them into account while preparing an updated set of patches.
787
+ </ p >
788
+ </ li >
789
+ < li >
790
+ < p >
791
+ Polish, refine, and re-send your patches to the list and to the people
792
+ who spent their time to improve your patch. Go back to step (2).
793
+ </ p >
794
+ </ li >
795
+ < li >
796
+ < p >
797
+ While the above iterations improve your patches, the maintainer may
798
+ pick the patches up from the list and queue them to the < code > seen</ code >
799
+ branch, in order to make it easier for people to play with it
800
+ without having to pick up and apply the patches to their trees
801
+ themselves. Being in < code > seen</ code > has no other meaning. Specifically, it
802
+ does not mean the patch was "accepted" in any way.
803
+ </ p >
804
+ </ li >
805
+ < li >
806
+ < p >
807
+ When the discussion reaches a consensus that the latest iteration of
808
+ the patches are in good enough shape, the maintainer includes the
809
+ topic in the "What’s cooking" report that are sent out a few times a
810
+ week to the mailing list, marked as "Will merge to < em > next</ em > ." This
811
+ decision is primarily made by the maintainer with help from those
812
+ who participated in the review discussion.
813
+ </ p >
814
+ </ li >
815
+ < li >
816
+ < p >
817
+ After the patches are merged to the < em > next</ em > branch, the discussion
818
+ can still continue to further improve them by adding more patches on
819
+ top, but by the time a topic gets merged to < em > next</ em > , it is expected
820
+ that everybody agrees that the scope and the basic direction of the
821
+ topic are appropriate, so such an incremental updates are limited to
822
+ small corrections and polishing. After a topic cooks for some time
823
+ (like 7 calendar days) in < em > next</ em > without needing further tweaks on
824
+ top, it gets merged to the < em > master</ em > branch and wait to become part
825
+ of the next major release.
826
+ </ p >
827
+ </ li >
828
+ </ ol > </ div >
829
+ < div class ="paragraph "> < p > In the following sections, many techniques and conventions are listed
830
+ to help your patches get reviewed effectively in such a life cycle.</ p > </ div >
831
+ </ div >
832
+ < div class ="sect2 ">
748
833
< h3 id ="choose-starting-point "> Choose a starting point.</ h3 >
749
834
< div class ="paragraph "> < p > As a preliminary step, you must first choose a starting point for your
750
835
work. Typically this means choosing a branch, although technically
@@ -945,8 +1030,9 @@ <h3 id="describe-changes">Describe your changes well.</h3>
945
1030
</ p >
946
1031
</ li >
947
1032
</ ol > </ div >
948
- < div class ="paragraph "> < p > The goal of your log message is to convey the < em > why</ em > behind your
949
- change to help future developers.</ p > </ div >
1033
+ < div class ="paragraph "> < p > The goal of your log message is to convey the < em > why</ em > behind your change
1034
+ to help future developers. The reviewers will also make sure that
1035
+ your proposed log message will serve this purpose well.</ p > </ div >
950
1036
< div class ="paragraph "> < p > The first line of the commit message should be a short description (50
951
1037
characters is the soft limit, see DISCUSSION in < a href ="git-commit.html "> git-commit(1)</ a > ),
952
1038
and should skip the full stop. It is also conventional in most cases to
@@ -1381,84 +1467,6 @@ <h2 id="_subsystems_with_dedicated_maintainers">Subsystems with dedicated mainta
1381
1467
</ div >
1382
1468
</ div >
1383
1469
< div class ="sect1 ">
1384
- < h2 id ="patch-flow "> An ideal patch flow</ h2 >
1385
- < div class ="sectionbody ">
1386
- < div class ="paragraph "> < p > Here is an ideal patch flow for this project the current maintainer
1387
- suggests to the contributors:</ p > </ div >
1388
- < div class ="olist arabic "> < ol class ="arabic ">
1389
- < li >
1390
- < p >
1391
- You come up with an itch. You code it up.
1392
- </ p >
1393
- </ li >
1394
- < li >
1395
- < p >
1396
- Send it to the list and cc people who may need to know about
1397
- the change.
1398
- </ p >
1399
- < div class ="paragraph "> < p > The people who may need to know are the ones whose code you
1400
- are butchering. These people happen to be the ones who are
1401
- most likely to be knowledgeable enough to help you, but
1402
- they have no obligation to help you (i.e. you ask for help,
1403
- don’t demand). < code > git log -p -- < em > $area_you_are_modifying</ em > </ code > would
1404
- help you find out who they are.</ p > </ div >
1405
- </ li >
1406
- < li >
1407
- < p >
1408
- You get comments and suggestions for improvements. You may
1409
- even get them in an "on top of your change" patch form.
1410
- </ p >
1411
- </ li >
1412
- < li >
1413
- < p >
1414
- Polish, refine, and re-send to the list and the people who
1415
- spend their time to improve your patch. Go back to step (2).
1416
- </ p >
1417
- </ li >
1418
- < li >
1419
- < p >
1420
- The list forms consensus that the last round of your patch is
1421
- good. Send it to the maintainer and cc the list.
1422
- </ p >
1423
- </ li >
1424
- < li >
1425
- < p >
1426
- A topic branch is created with the patch and is merged to < code > next</ code > ,
1427
- and cooked further and eventually graduates to < code > master</ code > .
1428
- </ p >
1429
- </ li >
1430
- </ ol > </ div >
1431
- < div class ="paragraph "> < p > In any time between the (2)-(3) cycle, the maintainer may pick it up
1432
- from the list and queue it to < code > seen</ code > , in order to make it easier for
1433
- people to play with it without having to pick up and apply the patch to
1434
- their trees themselves.</ p > </ div >
1435
- </ div >
1436
- </ div >
1437
- < div class ="sect1 ">
1438
- < h2 id ="patch-status "> Know the status of your patch after submission</ h2 >
1439
- < div class ="sectionbody ">
1440
- < div class ="ulist "> < ul >
1441
- < li >
1442
- < p >
1443
- You can use Git itself to find out when your patch is merged in
1444
- master. < code > git pull --rebase</ code > will automatically skip already-applied
1445
- patches, and will let you know. This works only if you rebase on top
1446
- of the branch in which your patch has been merged (i.e. it will not
1447
- tell you if your patch is merged in < code > seen</ code > if you rebase on top of
1448
- master).
1449
- </ p >
1450
- </ li >
1451
- < li >
1452
- < p >
1453
- Read the Git mailing list, the maintainer regularly posts messages
1454
- entitled "What’s cooking in git.git" giving
1455
- the status of various proposed changes.
1456
- </ p >
1457
- </ li >
1458
- </ ul > </ div >
1459
- </ div >
1460
- </ div >
1461
- < div class ="sect1 ">
1462
1470
< h2 id ="_github_ci_a_id_ghci_a "> GitHub CI< a id ="GHCI "> </ a > </ h2 >
1463
1471
< div class ="sectionbody ">
1464
1472
< div class ="paragraph "> < p > With an account at GitHub, you can use GitHub CI to test your changes
@@ -1582,7 +1590,7 @@ <h3 id="_gnus">Gnus</h3>
1582
1590
< div id ="footer ">
1583
1591
< div id ="footer-text ">
1584
1592
Last updated
1585
- 2024-05-13 12:26:57 PDT
1593
+ 2024-05-23 12:14:59 PDT
1586
1594
</ div >
1587
1595
</ div >
1588
1596
</ body >
0 commit comments