Introduce Workflow #65
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introductory material to understand how the workflow operates and its terminology and concepts in the software development domain compared to generic project managed. Includes a schedule. Also add a reference guide.
The Commitfest Workflow is a formalization and extension of the existing commitfest-only protocol. There is now some in-app documentation and the idea of moving patches to the "next CF" has begun being deprecated. Instead the UI provides the user valid choices on where to transition patches, which, with the introduction of the Drafts commitfest, is basically one or the other. Committers gain the ability to transition patches into In Progress if desired. Patches within In Progress commitfests can be moved into either Open or Drafts. Begin enforcement of a maximum of one commifest in each of Parked, Open, and In Progress. The workflow defines the drafts commitfest as lasting for one year matching up with the major release process. Namely, once the commifest leading up to feature freeze is In Progress a new Drafts commitfest should be created. With the workflow changes it is necessary for CFBot to be made aware of the specific commitfest ids that are active. Provide a JSON API for this purpose to begin weaning CFBot off scraping html. The workflow in-app documentation includes a month-based schedule showing which commifests are active, and their names, in each month (among other related details). Begin enforcing the existing rule that future commitfests cannot have patches via triggers. Future work on the administrative and UX aspects of the CFApp likely will do away with future commitfests altogether. Thoughts on the topic are welcome in the GitHub issues.
JelteF
reviewed
Apr 18, 2025
| operations = [ | ||
| migrations.RunSQL( | ||
| """ | ||
| CREATE FUNCTION assert_poc_not_future_for_poc() |
There was a problem hiding this comment.
As also said on the previous PR: Instead of messing around with triggers. We should simply remove the concept of future commitfests.
There was a problem hiding this comment.
I'll support that but don't have a desire to actually try and convince people to remove Future at this time. Its simple enough to just enforce the defacto policy that we no longer actually place patches into Future CFs.
|
@polobo thanks again for this PR, it's a nice approach. I'm currently working on refactoring this a bunch to make it shipable. I'll have a PR for that ready soonish. |
|
Okay, closing this in favor of #70 |
JelteF
added a commit
that referenced
this pull request
Jun 15, 2025
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. Fixes #25 Fixes #65 --------- Co-authored-by: David G. Johnston <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This a much pared down version of PR #62 . Please review that message for the big picture of where all of this is going.
For this PR the goal is to start down the path to improved UX and CFBot integration through formalization of existing processes, exposing an API, and adding the Parked/Drafts commitfest status. See the commit messages for more details.