Introduce Drafts page and automatic CF creation #70
Conversation
| A "patch" is a bit of an overloaded term in the PostgreSQL community. Email threads on the mailing list often contain "patch files" as attachments, such a file is often referred to as a "patch". A single email can even contain multiple related "patch files", which are called a "patchset". However, in the context of a CommitFest app a "patch" usually means a "patch entry" in the CommitFest app. Such a "patch entry" is a reference to a mailinglist thread on which change to PostgreSQL has been proposed, by someone sending an email that contain one or more "patch files". The CommitFest app will automatically detect new versions of the patch files and update the "patch entry" accordingly. | ||
| </p> | ||
| <p> | ||
| There are three active categories of patch status: |
There was a problem hiding this comment.
TODO: Somewhere should be "Returned with Feedback"
There was a problem hiding this comment.
In my mind it should either be rejected (or, ideally, withdrawn) or moved back into drafts. Trying to reduce the amount of choice presented to the user by omitting RfW - which isn’t really a descriptive “end state”. If no one accepts that logic it can be easily added.
JelteF
force-pushed
the
introduce-drafts-jelte
branch
from
b9dddce to
f05f885
Compare
This introduce a new type of CommitFest a "Draft" CommitFest. This CommitFest is never "In Progress", but it can be open. It exists for a year. It opens when the final regular CommitFest of the year becomes "In Progress" and stays open for exactly a year. It never becomes "In Progress" itself. Adding a second type of CommitFest also needed a redesign of quite a few things, like the homepage. Also management of the CommitFests needed to be made a bit easier, so admins don't forget to close/create Draft CommitFests. So now, closing/opening/creating CommitFests is done automatically when the time is right for that. A help page is also introduced to explain the CommitFest app. The naming of CommitFests has been changed too. Since we now have a Draft CF every year that needs a name, it seemed reasonable to align the names of the other CFs with that too. So each PG release cycle now has 5 regular commitfests that are called: - PG18-1 - PG18-2 - PG18-3 - PG18-4 - PG18-Final And a single Draft CommitFest, called: - PG18-Draft Finally, it also adds a small initial API endpoint for the CFBot, to request the commitfests that need CI runs. Future PRs will extend this API surface to also include/allow requesting the actual patches that CI should run on. Co-Authored-By: David G. Johnston <[email protected]>
JelteF
force-pushed
the
introduce-drafts-jelte
branch
from
f05f885 to
90792d1
Compare
|
Did you have specific rationale for choosing to add a draft Boolean instead of using a status? |
There was a problem hiding this comment.
We push patches written during an in progress cf all the time. Those should be able to be added to the in progress cf by a committer so their cf of record is correct. I.e., move to should show in progress conditionally.
|
Not a fan of the fundamental relevant cf getter method having non-cache related side effects that only ever trigger every other month or so. It isn’t even a pure date-related action; our final cf in particular has an end date that is changed during the months it happens in. We should,have a form to make the action easy to perform, but not remove the human component altogether. |
This introduce a new type of CommitFest a "Draft" CommitFest. This
CommitFest is never "In Progress", but it can be open. It exists for a
year. It opens when the final regular CommitFest of the year becomes "In
Progress" and stays open for exactly a year. It never becomes "In
Progress" itself.
Adding a second type of CommitFest also needed a redesign of quite a few
things, like the homepage. Also management of the CommitFests needed to
be made a bit easier, so admins don't forget to close/create Draft
CommitFests. So now, closing/opening/creating CommitFests is done
automatically when the time is right for that. A help page is also
introduced to explain the CommitFest app.
The naming of CommitFests has been changed too. Since we now have a
Draft CF every year that needs a name, it seemed reasonable to align the
names of the other CFs with that too. So each PG release cycle now has 5
regular commitfests that are called:
And a single Draft CommitFest, called:
Finally, it also adds a small initial API endpoint for the CFBot, to
request the commitfests that need CI runs. Future PRs will extend this
API surface to also include/allow requesting the actual patches that CI
should run on.
Fixes #25
Fixes #65