On Thu, May 30, 2019, at 3:18 PM, Kevin Fenzi wrote:
> As discussed in the EPEL SIG meeting yesterday, I've written
up my
> thoughts on how to handle epel8 branches.
[...]
>
> When the time comes where an incompatible change needs to land, they
> must be coordinated to land on an approved schedule. The exact
> mechanism of scheduling and coordinating this is out of scope for this
> document and will be decided on by the EPEL Steering Committee.
Yeah, but we should probibly try and figure it out.
I guess there is:
A. Right after the new minor release comes out
B. Right after the new minor release comes out for CentOS
C. Some arbitrary time after the new minor release comes out.
I'd be in favor of B.
[...]
> # Historical Composes
> Since major changes may occur at RHEL 8.Y releases, we want to support
> allowing our users to lock onto a repository that matches that
> release. For this, we will generate historical composes, which will
> match the stable package set of the prior minor release once the new
> minor release comes out.
>
> At 00:00 UTC of the day following a new RHEL 8.Y release, an updated
> epel-release package will be pushed, updating the %dist tag to the new
> .epel8_Y value. All new builds will thus have the new dist tag. A
> script will be run at this time to apply a new Koji tag (epel8-8.Y) to
> the latest build of a package with one of the following tags: [
> epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y
> repository will be created at this time from all packages currently
> tagged as epel8-8.Y.
So, we will also have to unpush/obsolete/close all pending bodhi updates
right? Since things will need rebuilding with the new dist tag for the
new minor.
I'd say just cancel any karma, reset the timer, then let them go out as-is once/if
they again pass the bodhi process.
>
> Historical composes are intended to be frozen and unchanging, but this
> approach leaves open the possibility of tagging other builds into
> epel8-8.Y and regenerating the compose if the need arises. It will
> need to be communicated that these repositories will not receive
> updates and are intended to be only a snapshot of the past that is
> known to work with a particular RHEL 8.Y base.
This will be very helpful, especially if the epel-release .repo file honors the
$releasever variable.
V/r,
James Cassell