3
3
< h2 > Key Concepts</ h2 >
4
4
< h3 > The Commitfest Workflow</ h3 >
5
5
< 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,
9
14
awaiting guidance, awaiting review, or waiting to be committed (status).
10
15
The workflow uses commitfests and patch status in combination to communicate
11
16
the overall state of the patch within these two categories.
12
17
</ p >
13
18
< p >
14
19
Commitfests are just bins filled with patches. Bins have a defined lifespan
15
20
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.
17
22
< ul >
18
- < li > Bugs - annual, all bug reports</ li >
19
23
< li > Drafts - annual, drafts for new features</ li >
20
- < li > Next - scheduled, proposed new features</ li >
24
+ < li > Open - scheduled, proposed new features</ li >
21
25
< li > Ongoing - scheduled, review and commit new features</ li >
22
26
</ ul >
23
27
There are three active categories of patch status covering the four statuses.
@@ -35,23 +39,17 @@ <h3>The Commitfest Workflow</h3>
35
39
</ ul >
36
40
(See notes below for all available statuses and their intended usage.)
37
41
</ 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 >
44
42
< p >
45
43
The drafts bin is where patches waiting on significant work go. A reviewer
46
44
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
48
46
with the committer patch status category already set.
49
47
</ p >
50
48
< 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) .
55
53
</ p >
56
54
< p >
57
55
The ongoing bin only exists during an active commitfest period, during which
@@ -60,11 +58,10 @@ <h3>The Commitfest Workflow</h3>
60
58
the bin is closed. This is only bin that is not present at all times.
61
59
</ p >
62
60
< 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".
68
65
</ p >
69
66
< h3 > Patches on Commitfests (PoC)</ h3 >
70
67
< h4 > Overview</ h4 >
@@ -112,7 +109,7 @@ <h4>Inactive</h4>
112
109
A Rejected patch has the same effect as Withdrawn but communicates that the
113
110
community, not the author, made the status change. This should only be used
114
111
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.
116
113
</ p >
117
114
< p >
118
115
*Returned With Feedback complements rejected in that the implication of rejected
@@ -123,9 +120,10 @@ <h4>Inactive</h4>
123
120
leaves reject as the fallback non-commit option and makes returned a deprecated
124
121
administrator-only option.
125
122
</ p >
123
+ < h3 > Special PoC Situations</ h3 >
126
124
< h4 > Moved</ h4 >
127
125
< 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
129
127
patches cannot be gotten to within a commitfest. In order to keep them visible
130
128
they must be moved to another commitfest, creating a new PoC with the same
131
129
state. The PoC they were moved from is updated to "Moved" to indicate this
@@ -137,6 +135,14 @@ <h4>Is Abandoned</h4>
137
135
but the commitfest is closed. Conceptually, this is the same as
138
136
withdrawn, but through inaction.
139
137
</ 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 >
140
146
< h3 > Patches</ h3 >
141
147
< h4 > Overview</ h4 >
142
148
< p >
@@ -183,17 +189,21 @@ <h4>Ongoing</h4>
183
189
An Active (see Workflow above) period where no new features should be added
184
190
and the goal is to get as many review"patches committed as possible.
185
191
</ p >
186
- < h4 > Future </ h4 >
192
+ < h4 > Open </ h4 >
187
193
< 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.
191
198
</ p >
192
- < h4 > Bugs </ h4 >
199
+ < h4 > Future </ h4 >
193
200
< 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.
197
207
</ p >
198
208
< h4 > Drafts</ h4 >
199
209
< p >
@@ -210,7 +220,7 @@ <h4>Drafts</h4>
210
220
</ p >
211
221
< h4 > Closed</ h4 >
212
222
< p >
213
- Drafts, bugs and ongoing commitfests are closed (future ones
223
+ Drafts and ongoing commitfests are closed (open ones
214
224
always go through ongoing) when the period they cover has passed.
215
225
Closing a commitfest does not impact its related PoCs; though no new PoCs can
216
226
be created for a closed commitfest.
0 commit comments