-
Notifications
You must be signed in to change notification settings - Fork 13
Introduce Workflow #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
operations = [ | ||
migrations.RunSQL( | ||
""" | ||
CREATE FUNCTION assert_poc_not_future_for_poc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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]>
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.