33 < h2 > Key Concepts</ h2 >
44 < h3 > The Commitfest Workflow</ h3 >
55 < p >
6- The commitfest workflow is a model for patch writing management.
7- There are a could of ways to classify patches. First, they can be introducing
8- new features or fixing existing bugs (type). Second, they can be awaiting changes,
6+ The commitfest workflow is a model for patch writing management. The workflow
7+ is designed to manage new feature patches. Bug fixes are typically handled
8+ without the overhead of creating patches in the Commitfest application.
9+ Thus the worflow broadly separates patches into "drafts" and
10+ "potentially committable". The former go onto the "Drafts v19" commitfest
11+ while the later are initially placed into the open commitfest, which is
12+ eventually converted into the ongoing commitfest.
13+ Second, they can be awaiting changes,
914 awaiting guidance, awaiting review, or waiting to be committed (status).
1015 The workflow uses commitfests and patch status in combination to communicate
1116 the overall state of the patch within these two categories.
1217 </ p >
1318 < p >
1419 Commitfests are just bins filled with patches. Bins have a defined lifespan
1520 after which they are "Closed" and a new bin for the same category is created.
16- Each bin serves a role in the workflow and there are 4 active categories of bins.
21+ Each bin serves a role in the workflow and there are 3 active categories of bins.
1722 < ul >
18- < li > Bugs - annual, all bug reports</ li >
1923 < li > Drafts - annual, drafts for new features</ li >
20- < li > Next - scheduled, proposed new features</ li >
24+ < li > Open - scheduled, proposed new features</ li >
2125 < li > Ongoing - scheduled, review and commit new features</ li >
2226 </ ul >
2327 There are three active categories of patch status covering the four statuses.
@@ -35,23 +39,17 @@ <h3>The Commitfest Workflow</h3>
3539 </ ul >
3640 (See notes below for all available statuses and their intended usage.)
3741 </ p >
38- < p >
39- The patches in the bugs bin are all of type "bug fix". The full lifecycle of
40- a bux fix patch lives here and there is no distinction as to the nature of the
41- reviewer category. The remaining bins exist to help deal with the large volume
42- of new feature patches.
43- </ p >
4442 < p >
4543 The drafts bin is where patches waiting on significant work go. A reviewer
4644 patch status category here mainly means awaiting guidance, though that will
47- often lead to a final review, allowing the patch to be moved to the future bin
45+ often lead to a final review, allowing the patch to be moved to the open bin
4846 with the committer patch status category already set.
4947 </ p >
5048 < p >
51- The future and ongoing bins are the ones that strictly comprise a commitfest.
52- The future bin always exists and new features ready for review and commit go
53- here. At scheduled points, the future bin becomes an ongoing bin and a new
54- future bin is created.
49+ The open and ongoing bins are the ones that strictly comprise a commitfest.
50+ The open bin always exists and new features ready for review and commit go
51+ here. At scheduled points, the open bin becomes an ongoing bin and a new
52+ open bin is created (possibly by reclassifying an existing future bin) .
5553 </ p >
5654 < p >
5755 The ongoing bin only exists during an active commitfest period, during which
@@ -60,11 +58,10 @@ <h3>The Commitfest Workflow</h3>
6058 the bin is closed. This is only bin that is not present at all times.
6159 </ p >
6260 < p >
63- The workflow is also designed with the release cycle in mind, in particular
64- the start of the annual feature freeze period. At this time both the drafts
65- and bugs bins are closed and new ones created. If the feature freeze is for
66- version 18 then the new drafts bin is called "Drafts v19" and the new bugs
67- bin is named "Bugs v18".
61+ The workflow is designed with the release cycle in mind, in particular
62+ the start of the annual feature freeze period. At this time the drafts
63+ bin is closed and a new one is created. If the feature freeze is for
64+ version 18 then the new drafts bin is called "Drafts v19".
6865 </ p >
6966 < h3 > Patches on Commitfests (PoC)</ h3 >
7067 < h4 > Overview</ h4 >
@@ -112,7 +109,7 @@ <h4>Inactive</h4>
112109 A Rejected patch has the same effect as Withdrawn but communicates that the
113110 community, not the author, made the status change. This should only be used
114111 when it is when the author is unable or unwilling to withdraw the patch or park
115- it for future rework.
112+ it for rework.
116113 </ p >
117114 < p >
118115 *Returned With Feedback complements rejected in that the implication of rejected
@@ -123,9 +120,10 @@ <h4>Inactive</h4>
123120 leaves reject as the fallback non-commit option and makes returned a deprecated
124121 administrator-only option.
125122 </ p >
123+ < h3 > Special PoC Situations</ h3 >
126124 < h4 > Moved</ h4 >
127125 < p >
128- Moved PoCs are a side-effect of having commitfest , and volume. Many active
126+ Moved PoCs are a side-effect of having commitfests , and volume. Many active
129127 patches cannot be gotten to within a commitfest. In order to keep them visible
130128 they must be moved to another commitfest, creating a new PoC with the same
131129 state. The PoC they were moved from is updated to "Moved" to indicate this
@@ -137,6 +135,14 @@ <h4>Is Abandoned</h4>
137135 but the commitfest is closed. Conceptually, this is the same as
138136 withdrawn, but through inaction.
139137 </ p >
138+ < h3 > Reverted Patches</ h3 >
139+ < p >
140+ Not every patch that is committed stays that way. The Workflow doesn't have
141+ any statuses for this, though the user interface does provide an action that
142+ a committer can invoke. Upon doing so the PoC status is updated to
143+ author. The history flow of commited followed by author indictes a probable
144+ revert.
145+ </ p >
140146 < h3 > Patches</ h3 >
141147 < h4 > Overview</ h4 >
142148 < p >
@@ -183,17 +189,21 @@ <h4>Ongoing</h4>
183189 An Active (see Workflow above) period where no new features should be added
184190 and the goal is to get as many review"patches committed as possible.
185191 </ p >
186- < h4 > Future </ h4 >
192+ < h4 > Open </ h4 >
187193 < p >
188- The next active (see workflow above) period.
189- Any patch not exempted to be added to the ongoing or bugs commitfests
190- can always be added here.
194+ Patches ready for final review and commit, according to the author, are placed
195+ in the current open commitfest. Upon the scheduled start date it is manually
196+ updated to be an ongoing commitfest, at which point no new patches should be
197+ added.
191198 </ p >
192- < h4 > Bugs </ h4 >
199+ < h4 > Future </ h4 >
193200 < p >
194- A commitfest for high-priority and bug fix patches. Full patch lifecycle.
195- Created as "Bugs v18" at the start of the v18 feature freeze period (closing
196- "Bugs v17").
201+ The PostgreSQL project works on a schedule release cycle. At the beginning
202+ of each cycle the planned commitfest periods are decided and communicated to
203+ the community via the creation of future commitfests. While classified as
204+ future these commitfests are not permitted to associated with any patches.
205+ Their classification is changed to open as each prior ongoing commitfest
206+ closes.
197207 </ p >
198208 < h4 > Drafts</ h4 >
199209 < p >
@@ -210,7 +220,7 @@ <h4>Drafts</h4>
210220 </ p >
211221 < h4 > Closed</ h4 >
212222 < p >
213- Drafts, bugs and ongoing commitfests are closed (future ones
223+ Drafts and ongoing commitfests are closed (open ones
214224 always go through ongoing) when the period they cover has passed.
215225 Closing a commitfest does not impact its related PoCs; though no new PoCs can
216226 be created for a closed commitfest.
0 commit comments