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 _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
