On Tue, Aug 13, 2024 at 10:17 AM Gary Buhrmaster <gary.buhrmaster@xxxxxxxxx> wrote: > > On Tue, Aug 13, 2024 at 9:12 AM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote: > > > This is something I wanted to do in previous EPEL splits, but it has usually gotten too many complaints from packagers to consider. Many packagers don't want their packages in EPEL at all but will do so if there are requests from someone or that there is going to be a branch packager for EPEL packages. Many EPEL branch packagers really only want to support one release because that is what they are using versus multiple ones. > > There is also the case (I had one), where a package > (in epel8) was later incorporated by RH into EL9, for > which automatic branch requests might have been an > issue (unless the automatic approval processes already > checks for that and rejects the branch request). When you request a branch this is actually verified twice. fedpkg checks the CentOS Stream compose metadata before filing the issue and it should reject the request (not even creating the issue) if the package already exists in that metadata (because that means it's already in RHEL, or on the way to RHEL soon). If somehow the issue gets filed anyways, the SCM toddler does the same check before creating the branch. If we were to automate things further, we'll definitely need to build a similar check into that process. > > > That said, I think it is something to revisit like we did for EL7, EL8 and EL9 :). > > Personally, automatic branching would work fine > for me, but often my bigger issue is opening the > bugzilla tickets for the often large dependency > chain for some scripting languages asking for > each package to be actually built, and then > waiting for the packager to have the resources > to build them. If one starts with the premise that > the packagers should control the creation of all > branches then auto-creating all those dependency > branch/build bugzillas (and *their* dependency > branch/build bugzillas, and so on) might be a > better step forward to reduce the process delays. > -- > _______________________________________________ > 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 > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
