< Changes
(updated summary) |
m (Add BZ) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 19: | Line 19: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= | = Track Changes in Taiga = | ||
The Motivation for this proposal is to propose using Taiga for | The Motivation for this proposal is to propose using the Taiga instance at teams.fedoraproject.org for Change processing. [[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously proposed for this. The new Change Processing workflow aims to simplify the process to improve visibility and ease of management. | ||
== Summary == | == Summary == | ||
| Line 32: | Line 32: | ||
The new process will consolidate much of the information in Taiga.Proposed Changes will be submitted as an issue in Taiga. The description of the Issue will include the content with few exceptions: | The new process will consolidate much of the information in Taiga.Proposed Changes will be submitted as an issue in Taiga. The description of the Issue will include the content with few exceptions: | ||
* System-Wide or Self-Contained change will be indicated by a | * System-Wide or Self-Contained change will be indicated by a boolean in the issue metadata | ||
* Fedora release will be indicated by a milestone 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 | * Change status will be indicated by a list selection in the issue metadata | ||
| Line 64: | Line 64: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1754661 #1754661] | ||
* Release notes tracker: <will be assigned by the Wrangler> | * Release notes tracker: <will be assigned by the Wrangler> | ||
| Line 72: | Line 72: | ||
The tool will be developed using Python 3.6+ and will interact with Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP. | The tool will be developed using Python 3.6+ and will interact with Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP. | ||
The General Workflow would be : | The General Workflow would be : | ||
# Change Owner opens an issue and fills in the fields. When they are ready to submit the Change proposal, they set the status to "Ready for Wrangler". | |||
# The Change Wrangler (FPgM) reviews the proposal. If it is incomplete, they set the status back to "New" and inform the Change Owner of what's needed. If it is ready to process, then... | |||
Functionality covered | |||
* Promote - The issue will be promoted to a user story in taiga,copies the contents of the custom fields from the issue to the user story. Closes the issue. | |||
* Announce - The tool would have the functionality to enable announcing the change proposal to devel and devel-announce lists using smtp. It will also automatically change the story status to announced. | |||
* fesco-submit - Allowing creation of a new issue in the FESco Pagure repo directly from the command line. | |||
* Accept - Once the changes are accepted the change-wrangler can create a tracking bug in Bugzilla along with release notes on Pagure.THe status of the user story is updated to accepted aswell. | |||
* Update - Status can be changed to testable if BZ is "Modified" and to Complete is BZ is "ON_QA" | |||
* Creation of Report - The user can create a report to provide quick view of changes and their status. It can be in wiki or Html form. | |||
Techstack: | Techstack: | ||
| Line 101: | Line 92: | ||
* Kerberos(For authentication) | * Kerberos(For authentication) | ||
The current sample arg created looks like this [ change-tool convert --taiga <issue no> <issue no> ] . The advantage of this the Manager would be able to specify unlimited no of issues to change at once in a single command using the issue no in taiga to convert to user story. | The current sample arg created looks like this [ change-tool convert --taiga <issue no> <issue no> ] . The advantage of this the Manager would be able to specify unlimited no of issues to change at once in a single command using the issue no in taiga to convert to user story. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 134: | Line 124: | ||
--> | --> | ||
The proposed change will make the change-process easier for everyone.Everyone would be able to see them in one place with status,id filters. The current wiki process can be bit difficult for formatting,having defined fields would mean easy access without the cumbersome wiki edits. | |||
Since changes would be submitted in Issue format on Taiga,pre-submission discussions would be available thus getting suggestions/feedback at the first stage itself would be easy for everyone involved. | |||
== Scope == | == Scope == | ||
| Line 197: | Line 189: | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
No other packages depend on this. | |||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 212: | Line 204: | ||
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --> | * Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --> | ||
Enough buffer time has been allocated to complete this during the GSoC period. | Enough buffer time has been allocated to complete this during the GSoC period. If this project is not implemented, the FPgM will convert existing Taiga cards to wiki pages. | ||
== Documentation == | == Documentation == | ||
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | ||
| Line 227: | Line 220: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF32]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 20:34, 23 September 2019
Track Changes in Taiga
The Motivation for this proposal is to propose using the Taiga instance at teams.fedoraproject.org for Change processing. Using Pagure was previously proposed for this. The new Change Processing workflow aims to simplify the process to improve visibility and ease of management.
Summary
The current process allows contributors to propose changes in upcoming Fedora releases. However, the management of those feature proposals is cumbersome and requires several manual steps. This introduces more opportunity for error and reduces the time available to the Change Wrangler for more valuable contributions to Fedora. In particular, the current process includes artifacts and discussion in the Fedora Wiki, on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this introduces more opportunity for error and reduces the time available for the Change Wrangler. A Cli Tool Written in Python that interacts with Taiga,Pagure and Bugzilla.Functionality includes Promoting,announcing,submitting,accepting and updating the changes across the three platforms and over mailing list.
The new process will consolidate much of the information in Taiga.Proposed Changes will be submitted as an issue in Taiga. The description of the Issue will include the content with few exceptions:
- System-Wide or Self-Contained change will be indicated by a boolean 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
Owner
- Name: Manas Mangaonkar
- Email: manasmangaonkar@gmail.com || pac23@fedoraproject.org
- Name: Ben Cotton
- Email: bcotton@redhat.com
Current status
- Targeted release: Fedora 32
- Last updated: 2019-09-23
- Tracker bug: #1754661
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed to smooth out the workflow,reduce Manual Work involved for both the Contributors and the Change-Wrangler(FPgm). The tool makes it easy by covering all the functionality required for the process of moving forward proposals.
The tool will be developed using Python 3.6+ and will interact with Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP. The General Workflow would be :
- Change Owner opens an issue and fills in the fields. When they are ready to submit the Change proposal, they set the status to "Ready for Wrangler".
- The Change Wrangler (FPgM) reviews the proposal. If it is incomplete, they set the status back to "New" and inform the Change Owner of what's needed. If it is ready to process, then...
Functionality covered
- Promote - The issue will be promoted to a user story in taiga,copies the contents of the custom fields from the issue to the user story. Closes the issue.
- Announce - The tool would have the functionality to enable announcing the change proposal to devel and devel-announce lists using smtp. It will also automatically change the story status to announced.
- fesco-submit - Allowing creation of a new issue in the FESco Pagure repo directly from the command line.
- Accept - Once the changes are accepted the change-wrangler can create a tracking bug in Bugzilla along with release notes on Pagure.THe status of the user story is updated to accepted aswell.
- Update - Status can be changed to testable if BZ is "Modified" and to Complete is BZ is "ON_QA"
- Creation of Report - The user can create a report to provide quick view of changes and their status. It can be in wiki or Html form.
Techstack:
- Python3.6+
- SMTP
- Taiga/Pagure/Bugzilla API's
- Nano/Gedit/Vi ( Inbuilt support to edit text)
- Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert --taiga <issue no> <issue no> ] . The advantage of this the Manager would be able to specify unlimited no of issues to change at once in a single command using the issue no in taiga to convert to user story.
Benefit to Fedora
The proposed change will make the change-process easier for everyone.Everyone would be able to see them in one place with status,id filters. The current wiki process can be bit difficult for formatting,having defined fields would mean easy access without the cumbersome wiki edits.
Since changes would be submitted in Issue format on Taiga,pre-submission discussions would be available thus getting suggestions/feedback at the first stage itself would be easy for everyone involved.
Scope
- Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the summer to create this tool from scratch.
- Other developers: N/A (not a System Wide Change)
- Release engineering: #Releng issue number (no release engineering impact is expected)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Other than the regular updation of the change-wrangler package nothing else will be required.
N/A (not a System Wide Change)
How To Test
N/A (not a System Wide Change)
User Experience
No visible Impact is expected.
Dependencies
No other packages depend on this.
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Enough buffer time has been allocated to complete this during the GSoC period. If this project is not implemented, the FPgM will convert existing Taiga cards to wiki pages.
Documentation
Detailed documentation will be done once the coding part of the tool is done.Documentation has been scheduled for july 25th and after.
N/A (not a System Wide Change)