From Fedora Project Wiki
< Changes
(→Release Notes: Based on the FESCo decision deferring this Change to F26: https://fedorahosted.org/fesco/ticket/1606#comment:3) |
Bowlofeggs (talk | contribs) (Update the change to target F27, owned by me, and mark it as ready for a wrangler.) |
||
| Line 33: | Line 33: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
* Name: [[User: | * Name: [[User:Bowlofeggs| Randy Barlow]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: | * Email: bowlofeggs@fedoraproject.org | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
| Line 46: | Line 46: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/27 | Fedora 27 ]] | ||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
| Line 164: | Line 164: | ||
--> | --> | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- 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 --> | ||
Revision as of 16:27, 28 October 2016
Bodhi Non-RPM Artifacts
Summary
Bodhi, the Fedora Updates System, should be able to process more than just RPMs.
Owner
- Name: Randy Barlow
- Email: bowlofeggs@fedoraproject.org
- Release notes owner:
Current status
Detailed Description
As Fedora starts to deliver more than just RPMs and ISOs, we need a way to handle delivering updates to these artifacts. Bodhi currently handles this workflow for RPMs only, but we want to start using it for other content, such as Docker containers, Flatpak apps, OSTrees, etc. If it can be tagged in Koji, it should be accepted by Bodhi.
Benefit to Fedora
By using Bodhi for the updates process for all artifacts, we are able to better leverage community testers, enforce gating based on automated test results, handle bugzilla interactions, send email announcements, etc.
Scope
- Proposal owners:
- Database model changes
- Masher modifications to the push process
- Web UI changes
- CLI modifications
- Unit tests
- Documentation
- Upstream tracker issue: https://github.com/fedora-infra/bodhi/issues/653
- Other developers: N/A (not a System Wide Change)
- QA: Taskotron will need handle kicking off tests for non-RPM updates
- QA: Client-side updates-testing tools like fedora-easy-karma could optionally be updated to detect these new artifacts
- Release engineering:
- We will need to ensure that the current signing process will work with non-RPM content
- Ensure that the new content has a proper home in the directory structure.
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
- Once a non-RPM artifact is built and tagged in Koji, the maintainer should be able to submit it to Bodhi.
- The maintainer should be able to set the karma thresholds and require gating based on any Taskotron or Wiki-based test.
- Testers should be able to submit feedback.
- Release engineering should be able to "push" the content out in the standard updates process.
User Experience
- Users of these various components will notice more frequent updates, ideally with more stability and less breakage.
Dependencies
- This plan relies on these artifacts having tags in Koji.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- We can simply switch back to the old compose processes for these components instead of using Bodhi.
- Contingency deadline: F25 Beta
- Blocks release? No
- Blocks product? No
Documentation
N/A (not a System Wide Change)