From Fedora Project Wiki

(Updated formatting)
Line 1: Line 1:
This is a shorthand list of items we are needing to cover for building Rawhide Gating in Fedora Infrastructure for the Fiscal Year 2020.
+
==Document Details==
 +
 
 +
* '''Status:'''<span style="background:#00FFFF">WORKING DRAFT</span>:
 +
* '''Point of contact:''' Pingou
 +
* '''Implementation Schedule:''' TBD
 +
* '''Release Date:''' TBD
 +
 
 +
==Goals==
 +
We want to gate packages on test results before they can land in rawhide. This will reduce the amount of broken dependency, uninstallable packages and broken composes leading to a more stable rawhide as well as less work on the infrastructure and rel-eng teams to keep composes working. The benefits to Fedora for implementing this:
 +
 
 +
* As more packagers opt-into gating and add tests to their packages, rawhide becomes more stable
 +
* More stable rawhide will lead to easier composes and a smoother release process
 +
* Ability to use chain-build in rawhide and stable releases
 +
 
 +
==Background and Strategic Fit==
 +
 
 +
To be completed.....
 +
 
 +
== Who is Requesting this ==
 +
 
 +
Stakeholder information to be completed here....who is requesting this? Who should be involved? Who needs to help sign off on things?
 +
 
 +
== Assumptions==
 +
 
 +
Are there any assumptions for completing this work?
  
Point of contact: Pingou
 
  
Time for implementation: 2020-03-31(?)
+
== Additional Links ==
  
 
Change proposal: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
 
Change proposal: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
 +
 +
== Initial User Story ==
 +
 +
A minimum user story list should be prepared here to facilitate Task Breakdown. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. Format should be:
 +
 +
As a < type of user >, I want < some goal > so that < some reason >.
  
 
== Task breakdown ==
 
== Task breakdown ==
 +
 +
This is a shorthand list of items we are needing to cover for building Rawhide Gating in Fedora Infrastructure for the Fiscal Year 2020.
  
 
==== Bodhi ====
 
==== Bodhi ====

Revision as of 14:55, 4 February 2019

Document Details

  • Status:WORKING DRAFT:
  • Point of contact: Pingou
  • Implementation Schedule: TBD
  • Release Date: TBD

Goals

We want to gate packages on test results before they can land in rawhide. This will reduce the amount of broken dependency, uninstallable packages and broken composes leading to a more stable rawhide as well as less work on the infrastructure and rel-eng teams to keep composes working. The benefits to Fedora for implementing this:

  • As more packagers opt-into gating and add tests to their packages, rawhide becomes more stable
  • More stable rawhide will lead to easier composes and a smoother release process
  • Ability to use chain-build in rawhide and stable releases

Background and Strategic Fit

To be completed.....

Who is Requesting this

Stakeholder information to be completed here....who is requesting this? Who should be involved? Who needs to help sign off on things?

Assumptions

Are there any assumptions for completing this work?


Additional Links

Change proposal: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages

Initial User Story

A minimum user story list should be prepared here to facilitate Task Breakdown. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. Format should be:

As a < type of user >, I want < some goal > so that < some reason >.

Task breakdown

This is a shorthand list of items we are needing to cover for building Rawhide Gating in Fedora Infrastructure for the Fiscal Year 2020.

Bodhi

  • Single package update
    • We will need to write a message-bus listener that will automatically create a bodhi update for each package built in the rawhide-gated tag.
    • We will need to write a message-bus listener to automatically push bodhi updates created for rawhide that have passed CI (the decision being announced by Greenwave).
  • Multi package update
    • We will need to allow bodhi to create a new update from a specified side-tag instead of a list of builds.
    • We will need to write a message-bus listener that, upon greenwave notifications about an update created from a side-tag passing CI, will move all of its builds into the rawhide-candidate tag and clean the side-tag created for this update.
    • We will need to write a script that regularly clean old side-tags left around

Koji

  • We will need a koji plugin allowing packagers to create new side-tags

fedpkg/rpkg

  • We will need to add support for the command: fedpkg side-tag create which will create a new side-tag in koji for this user using the new plugin
  • We will need to add support for the command: fedpkg side-tag merge which will call bodhi to ask it to create an update corresponding to this side-tag
    • Alternatively: Expand the existing fedpkg update command to add support for creating a new update from a side-tag