From Fedora Project Wiki
 
(11 intermediate revisions by 2 users not shown)
Line 12: Line 12:
* Targeted release: [[Releases/24 | Fedora 24 ]]  
* Targeted release: [[Releases/24 | Fedora 24 ]]  
* 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}}  
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1290431 #1290431]


== Detailed Description ==
== Detailed Description ==
Line 20: Line 20:
== Benefit to Fedora ==
== Benefit to Fedora ==


The benefit to Release Engineering should be self-evident: less tools, hosts, and services to maintain. This opens the door a little to let a small set of users generate their own signed repositories from Koji if they want to as well. This may be useful for QA testing.
The benefit to Release Engineering should be self-evident: less tools, hosts, and services to maintain. This opens the door a little to let a small set of users generate their own signed repositories from Koji if they want to as well. This may be useful for QA testing. Bodhi may also make use of this feature to release updates to users.
 
 
== Scope ==
== Scope ==
* Proposal owners: Jay Greguske
* Proposal owners: to implement this change


* Release engineering: This feature does require coordination with release engineering (e.g. changes to installer image generation or update package delivery.)
* Release engineering: This feature does require coordination with release engineering (e.g. changes to installer image generation or update package delivery.)


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
No effect on Fedora users directly.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
In the unlikely event that Fedora Rel-Eng needs to restore a release from scratch (from a compromised host, or major data loss event) the old process will still need to exist for Fedora 23.
N/A (not a System Wide Change)  


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
The feature affects how Fedora is composed, how images are generated, and potentially how the distribution is delivered. It does not affect the software itself, so this does not bring in any additional functional testing. Composes generated with the new Koji feature should function just as the previous ones did with no disruption to QA consumption of the content.
 
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
 
A good "how to test" should answer these four questions:
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
This does not require any new hardware nor actions from the user base.
N/A (not a System Wide Change)


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
This feature should not affect user experience in any way.
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Dependencies ==
== Dependencies ==
<!-- 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)? -->
This work does not depend on any external factors within the distro.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Pungi and mash's future implementations do have a dependency on this work. This is an enabler to other future Koji features as well.
N/A (not a System Wide Change)


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: Just use the old process for generating Fedora composes and delivering them.
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Blocks release? Probably not.
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? Nope
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
Line 82: Line 62:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF24]]
<!-- 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 13:56, 10 December 2015

Koji Generates Repositories of Signed RPMs

Summary

Extend Koji with a new feature that allows users to generate yum repositories of signed RPMs.

Owner

  • Name: Jay Greguske
  • Email: jgregusk with the usual red hat domain
  • Release notes owner:

Current status

Detailed Description

This is a significant enabler for generating DVD media, other ISOs, and images more efficiently. It also allows other tools such as mash or pungi to offload much of the heavy-lifting to the build system. Longer term, we may be able to reduce the number of tools needed to manufacture Fedora releases.

Benefit to Fedora

The benefit to Release Engineering should be self-evident: less tools, hosts, and services to maintain. This opens the door a little to let a small set of users generate their own signed repositories from Koji if they want to as well. This may be useful for QA testing. Bodhi may also make use of this feature to release updates to users.

Scope

  • Proposal owners: to implement this change
  • Release engineering: This feature does require coordination with release engineering (e.g. changes to installer image generation or update package delivery.)

Upgrade/compatibility impact

No effect on Fedora users directly.

In the unlikely event that Fedora Rel-Eng needs to restore a release from scratch (from a compromised host, or major data loss event) the old process will still need to exist for Fedora 23.

How To Test

The feature affects how Fedora is composed, how images are generated, and potentially how the distribution is delivered. It does not affect the software itself, so this does not bring in any additional functional testing. Composes generated with the new Koji feature should function just as the previous ones did with no disruption to QA consumption of the content.

This does not require any new hardware nor actions from the user base.

User Experience

This feature should not affect user experience in any way.

Dependencies

This work does not depend on any external factors within the distro.

Pungi and mash's future implementations do have a dependency on this work. This is an enabler to other future Koji features as well.

Contingency Plan

  • Contingency mechanism: Just use the old process for generating Fedora composes and delivering them.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? Probably not.
  • Blocks product? Nope

Documentation

This should not affect Fedora documentation for users, but it will affect Standard Operating Procedures (SOPs) for Rel-Eng. If the current process to build and release Fedora is documented anywhere, it will need to be updated.

Release Notes