On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote: > Here is my rough outline of the steps required to implement this proposal. > I imagine things would happen roughly in this order, but some things could > probably take place in parallel. > > 1. EPEL Steering Committee approves the proposal > 2. koji changes: > - create CentOS Stream 8 external repo > - create epel8-next build target (inheriting from epel8) > - dist macro override for that target > 3. create PDC entries > 4. update fedscm-admin with branch SLAs > 5. configure dist-git to allow branch name > 6. update pungi config > 7. add epel-next-repo subpackage to epel-release > 8. add epel8-next release in bodhi > 9. document in the wiki > 10. announcement email > > Please let me know if I'm missing anything. Looks pretty good to me, but two things: 1. I assume (but good to ask) that we are not going to change anything in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there? 2. We are heading into final freeze for Fedora 33 next tuesday, so not sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over? Thanks much for putting this together! kevin -- > > On Wed, Sep 23, 2020 at 8:43 PM Carl George <carl@xxxxxxxxxx> wrote: > > > > I agree, using .el8.next for the dist macro makes the most sense. This will > > enable maintainers to use a similar workflow to Fedora branches, where older > > branches can be fast forwarded, and the same commit can be built for > > different targets but still have different NVRs in Koji. Here is an example > > workflow for a fictional foo package that already exists in Fedora. > > > > - request epel8 branch > > - merge master branch to epel8 branch > > - build epel8 branch, resulting in foo-1-1.el8 > > - realize it won't install on CentOS Stream due to a library difference > > - request epel8-next branch > > - merge epel8 branch to epel8-next branch > > - build epel8-next branch, resulting in foo-1-1.el8.next > > > > After the next RHEL 8 minor release (when that library difference affects > > everyone), the maintainer can increment the release on the epel8 branch and > > proceed as usual. > > > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > > At the EPEL Steering Committee last week, we had an extensive discussion of > > > > this proposal, specifically focused on how to handle the dist macro. I > > > > believe these are the possible choices. > > > > > > > > * keep dist the same as epel8 (.el8) > > > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for > > > > dist. It would make sense to continue using the same dist for EPEL Next. > > > > However, this would put a little more work on packagers. They would not be > > > > able to build the same commit for both EPEL and EPEL Next because the NVR > > > > will conflict in Koji. In simple rebuild situations, this is not a problem > > > > because at a minimum the release will be higher. But if a packager wanted > > > > to update the package in both EPEL and EPEL Next, they will need to first > > > > update and build it in EPEL, then bump the release and build it in EPEL > > > > Next. This isn't ideal, but isn't terrible either, and can be partially > > > > mitigated by good documentation around EPEL Next workflows. > > > > > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > > > > > In EPEL Next we could define dist to a string that RPM evaluates higher than > > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be > > > > in sync and the same commit could be built for both targets. The higher > > > > dist would ensure the upgrade path works. > > > > > > I think this makes the most sense and will help packages workflows the > > > best. > > > > > > kevin > > > _______________________________________________ > > > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > -- > > Carl George > > > > -- > Carl George > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
