Let us know how you should track this. Who you should contact? Who the owner is? What IRC channel are we in?
CPE Appointed Owner: TBD
CPE Appointed Manager: TBD
CPE Collaborators: Kevin Fenzi, Stephen Smoogen, Fabian Arrotin, Brian Stinson, Johnny Hughes. Troy Dawson
Key Stakeholder: Stephen Gallagher (modularity?), Mike McGrath?
IRC Channel: #epel, #fedora-devel
Taiga Link:
It is important to keep track of the evolution of the requirements document. Here, we can track key changes and milestones.
Version | Details | Updated By | Date |
1.0 | First initial Draft for review | Leigh Griffin | 2019-04-29 |
1.1 | Fork to EPEL | Stephen Smoogen | 2019-05-09 |
1.2 | Announce to group | Stephen Smoogen | 2019-05-15 |
When writing a requirements document intended for the CPE team, a number of key items need to be included in order to help with initial reviews and later prioritisation and scheduling.
The following sections are required before this doc is ready for the team to consume. An example spec for reference is the Rawhide Gating spec. The sections below are not exhaustive, and the CPE team should evolve them based on their domain knowledge. The principle of each heading in this Template should be used to guide the requirements. If a heading is omitted, the spirit of what it is trying to achieve should be included in other sections.
Extra Packages for Enterprise Linux (EPEL) is an add-on composition of Fedora sources recompiled for versions of Red Hat Enterprise Linux (RHEL). We need to be able to produce an EPEL repository after general release which Fedora developers can branch into, EPEL consumers can easily get packages out of.
EPEL started as a recompilation of tools from Fedora that were not shipped with Red Hat Enterprise Linux, but were needed for Fedora to actually use RHEL for its own production. Because these packages were useful for others, it was added as a working group inside of Fedora and more packages were added over time. Initially designed to be built for a 5 year lifetime of a nearly static RHEL-4, the way it was built and composed no longer matches current RHEL’s 10 year lifetimes with major updates. This means that starting up a new release to match RHEL-8 is going to take changes throughout the infrastructure.
EPEL has grown greatly in use from its original release time. The mirror servers track million’s of systems and networks which check for daily updates. This has made it a prime distribution point for FLOSS software to enterprise systems.
EPEL-7 beta released in January of 2014, shortly after the RHEL-7 beta. It reached General Availability (GA) in 28 August 2014, roughly 10 weeks after the RHEL7 GA, and around a month after CentOS GA. This was possible because the Fedora release engineer had worked on the RHEL-7 release cycle and could put in place changes needed from that experience. Earlier releases took longer or shorter depending on the amount of changes needed to make the systems work
There are multiple requesters for this project:
We want to avoid surprises to the development team in the middle of working on a request. At best a surprise can add more time to a project, at worst, it can lead to it failing. A big part of protecting both the team and indeed the feature being requested is calling out any Assumptions that the requester is making while putting together the spec.
Assumption | Raised By | Plan of Action |
We can build without CRB | Kevin Fenzi | Circulate for review |
By using grobbisplitter we can break each RHEL-8 module into separate repos which we can choose to merge into one major with mergerepo | Stephen Smoogen | Circulate for review |
EPEL-8.0 will not build modules | Stephen Smoogen | Circulate for review |
We will not expect all RHEL-7 equivalent packages to be able to build for EPEL-8. | Stephen Smoogen | Circulate for review |
A set of overview User Stories which covers the requested feature/enhancement in full. The details here can be at a high level and initially do not need to have Acceptance Criteria at this point in time.
Clearly outline the Actors, whom are the end users of this. Differentiate any User Stories from a functionality point of view. We call this Personas, for example:
Format to try and adhere to:
Story Number | Group | User Story | Importance | Acceptance Criteria |
1 | ? | As a User, I want…. | Must Have | TBD |
2 | ? | |||
3 | ? | |||
4 | ? |
These problems mean that certain trees may need additional libraries which are not currently in EPEL.
Canary builds of packages with the RHEL-8 beta showed that many packages can’t be built without additional tools inside of koji to deal with modularity and filtered packages. Koji cannot currently comprehend the combination of modules and packages inside the AppStream repository.
As a result, it is impossible to import this repo in a way the build system can use, and impossible to build anything useful without it. To do so manually -- for example, by blacklisting or whitelisting -- becomes a game of chase the team isn’t resourced for.
Similarly, mass rebuilding a subset of packages for public consumption generates additional problems:
However, these problems can be avoided by putting proper tooling changes in place and allowing maintainers to branch and build, as they did in previous EPEL. The modularity team have provided repo tool changes (createrepo_c and mergerepo_c) that are needed. Once the Koji team finishes changes needed, we can build a “real” EPEL that works.
We don’t throw things away. The User Story list above should be our Minimum Viable Product (MVP), anything descoped should be copied from the Table above to the Table here so we can potentially have a Phase II.
Story Number | Group | User Story | Importance | Acceptance Criteria |
When: 9 May, unless Fedora 30 misses its release, then work will begin 15 May.
How Long: 2 weeks
Where: Staging instance of the Fedora build system (koji and mbs)
Who:
What: A repository of packages, not attached to epel-release.rpm, which are offered with caveat emptor guidance and built against regular RPM (“ursine”) package content only.
How: During the POC we will
These packages are only as an example and will not show up in src.fedoraproject.org or bugzilla. These will be done in the fedora stg koji infrastructure.
When: After tools and fixes identified in stage 1 have been deployed in staging and production
How Long: 4-6 weeks
Where: Production instance of the Fedora build system (koji and mbs)
What (Deliverable): A repository of signed packages which can be built against the RHEL-8 ursine packages. Packages from ‘modules’ packages will be pulled in but will be treated as ‘ursine’ by the build system. Packages will only be those that Fedora maintainers branch and build.
Who:
Prerequisites:
How: During the beta we will
Out of scope for Beta: During this initial build, CPE will not:
Caveats: During the beta, we may need to back out changes, alter the build system repositories, etc, so during this time beta consumers should be aware that unannounced changes and updates will happen. These packages are not automatically assumed to be maintained by the community, and some may be removed for EPEL-8 final. Upgrades from these packages to final EPEL may not be possible.
Done:
We will consider the beta to a 2 to 3 week sprint for tools and configs, and then 2-3 weeks for getting initial content. Once all initial packages in the initial set that can be built without complex modifications have been built. Once the beta period is over, we will consider the result a EPEL-8.0 final candidate. This candidate will then be composed into the regular /pub/epel tree with an updates tree for package updates.
When: After any needed features have been addressed in the tooling by the responsible teams. Hopefully those features would land around 8.1 GA.
What:
Who:
How: During the final development cycle we will:
Out of Scope:
Done: We’re done when contributors can effectively review/branch/build packages for EPEL in both ursine and modular form. This will require additional time to spec and deliver due to complexity, and pre-existing priorities in CPE.
A build set was done of EPEL packages with a subset of RHEL-8 that has no modularity in it. Removing all easily known not to build packages (aka all python-X, rust-X, etc), the following were found to be needed dependencies in what looked like ‘ordinary’ packages