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. * modify dist to reflect future rhel version (.el8_3) This is similar to the previous choice as far as the upgrade path. It would make things a bit more obvious during the CentOS Linux rebuild gap. For example, a user who upgrades from RHEL 8.2 to 8.3 could grab a .el8_3 build from EPEL Next if the EPEL package hasn't been rebuilt yet. However, the dist could be misleading. Building against CentOS Stream at a given point in time doesn't necessarily give you all the libraries that will be in the next final RHEL minor release. There will be situations early in the cycle where some libraries have changed and others that will haven't yet. Additionally, there will be a short period of time late in the cycle where CentOS Stream will have release+2 content prior to release+1 reaching RHEL GA. Leaving the minor release out of the dist leaves us more wiggle room on user expectations. We need to make a decision on dist before moving further. Here are some other thoughts from the meeting: - epel-next-release as a subpackage of epel-release - automatic nightly compose or bodhi enablement? - start enumerating the steps necessary to move forward (WIP) On Wed, Sep 9, 2020 at 2:55 PM José Abílio Matos <jamatos@xxxxxxxx> wrote: > > On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote: > > > From a mulit-language perspective, I prefer not to use '4' in place of > > > the English word 'for'. It makes the translation work a bit wonky. > > > Not only that, do not forget the meaning/association of 4 in different cultures. :-) > > > -- > > José Abílio > > _______________________________________________ > 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 _______________________________________________ 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
