From Fedora Project Wiki

Revision as of 16:39, 20 June 2016 by Lmacken (talk | contribs)

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.


Bodhi Non-RPM Artifacts

Summary

Bodhi, the Fedora Updates System, should be able to process more than just RPMs.

Owner

  • Name: Luke Macken
  • Email: lmacken@redhat.com
  • Release notes owner:

Current status

  • Targeted release: Fedora 25
  • Last updated: 2016-06-20
  • Tracker bug: <will be assigned by the Wrangler>

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

  • 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.
  • 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: N/A (not a System Wide Change)
  • Blocks release? No
  • Blocks product? No

Documentation

N/A (not a System Wide Change)

Release Notes