From Fedora Project Wiki
(Created page with "= Use Pagure for Change Wrangling = Summary: the current Fedora Change Process involves independently-managed artifacts across a variety of platforms. Thi...") |
No edit summary |
||
| Line 44: | Line 44: | ||
* Pagure date reporting is not robust (e.g. a comment left on the issue will change the modified timestamp of the issue). This will require more careful scripting for time-based reports (e.g. by using a manually-assigned due date) | * Pagure date reporting is not robust (e.g. a comment left on the issue will change the modified timestamp of the issue). This will require more careful scripting for time-based reports (e.g. by using a manually-assigned due date) | ||
* External processes that depend on Bugzilla tickets (if any?) will need to be adjusted | * External processes that depend on Bugzilla tickets (if any?) will need to be adjusted | ||
* We lose edit history if a change proposal is updated based on feedback | |||
== Technology changes == | == Technology changes == | ||
| Line 49: | Line 50: | ||
* '''Add the ability to create dependencies between issues in different repos''' — Allows links to docs and FESCo tickets. Workaround: manually include links in comments. | * '''Add the ability to create dependencies between issues in different repos''' — Allows links to docs and FESCo tickets. Workaround: manually include links in comments. | ||
* '''Add 'Due Date' as an issue field''' — Allows easier reporting of issues based on due date. Workaround: use a text string formatted as an ISO-8601 date. | * '''Add 'Due Date' as an issue field''' — Allows easier reporting of issues based on due date. Workaround: use a text string formatted as an ISO-8601 date. | ||
* ''''Add edit history'for issues ''' — Allows visibility of how a Change has evolved in response to feedback | |||
Revision as of 15:53, 6 July 2018
Use Pagure for Change Wrangling
Summary: the current Fedora Change Process involves independently-managed artifacts across a variety of platforms. This proposal aims to simplify the process to improve visibility and ease of management.
Current Process
The current process includes artifacts and discussion in:
- Fedora Wiki
- mailing lists
- FESCo ticket
- Bugzilla ticket
- Docs ticket
This creates a lot of management overhead, introduces opportunities for errors, and inhibits visibility.
New Process
The new process will consolidate much of the information in Pagure. Proposed Changes will be submitted as an issue in the Fedora Changes repo. The description of the issue will include the content, with a few exceptions:
- System-Wide or Self-Contained change will be indicated by a binary in the issue metadata
- Fedora release will be indicated by a milestone in the issue metadata
- Change status will be indicated by a list selection in the issue metadata
Workflow
- Change Owner creates a new issue in the Fedora Changes repo.
- Change Owner sets the Ready for Wrangler status on the issue when it is ready.
- Change Wrangler reviews the change for completeness.
- Change Wrangler' announces changes on mailing lists for discussion and changes status to "Announced" (this can be scripted, e.g.
fedora_changes announce 3) - Change Wrangler creates FESCo ticket after waiting period and changes status to Ready for FESCo (this can be scripted)
- FESCo votes on change.
- Change Wrangler collects votes and updates status to "Accepted" or "Rejected"
- Change Wrangler closes Rejected Changes. Change Owner may re-open issue to address rejection reasons or to resubmit for the next release.
- Change Wrangler creates new issue in the Release Notes repo for Accepted changes.
- Change Owner sets the status to Complete when the change is complete
- Change Wrangler monitors status of changes and works with FESCo and Change Owner to delay changes that do not meet deadline.
Advantages
- Pagure repo becomes a single source for change information
- Eliminates Wiki and Bugzilla as artifact locations
- Workflow steps can be more easily scripted because change metadata is partially separated from content
- Automatic report generation is easier
Disadvantages
- Still requires changes be represented in three different Pagure repos
- Pagure date reporting is not robust (e.g. a comment left on the issue will change the modified timestamp of the issue). This will require more careful scripting for time-based reports (e.g. by using a manually-assigned due date)
- External processes that depend on Bugzilla tickets (if any?) will need to be adjusted
- We lose edit history if a change proposal is updated based on feedback
Technology changes
Pagure
- Add the ability to create dependencies between issues in different repos — Allows links to docs and FESCo tickets. Workaround: manually include links in comments.
- Add 'Due Date' as an issue field — Allows easier reporting of issues based on due date. Workaround: use a text string formatted as an ISO-8601 date.
- 'Add edit history'for issues — Allows visibility of how a Change has evolved in response to feedback