On 08. 07. 21 2:28, Mohan Boddu wrote:
Also, people who wish to opt out of this mass rebuild can add
'noautobuild' file to the epel9-next branch beforehand, this however
does not stop from creating the epel9 branch, just the package won't
be included in the rebuild.
I think there are 3 possible opt outs here:
1) The epel9-next packager does not intent to maintain the package in epel9,
only in epel9-next. While we might not like this goes, as long as there is no
policy against this approach, always creating the branch will create work for
the packager they have not signed for. I think there should be an opt out for
branching as well.
2) The epel9-next packager does intent to maintain the package in epel9,
however the commits in the epel9-next branch already contain stuff that is
necessary for c9s but doe snot work with RHEL 9.0. They want to branch for
epel9, but from an earlier commit, so they don't need to revert and eventually
unrevert later. (Yes, I know they could potentially build from an older commit,
but that's not very transparent and many packagers don't do that.) I think
there should be an opt out for branching with all the comits as well (i.e. opt
in to create the epel9 branch empty).
3) The epel9-next packager does intent to maintain the package in epel9, all
the commits are fine, but they intent to do manual bootstrapping themselves. I
agree there should be an opt out for automatically rebuilding the package.
However, I don't think the noautobuild file in git is ideal. At this point of
EL 9 life cycle, many packagers are likely to at least attempt to maintain
Fedora and EPEL 9 packages from identical branches. By requiring to add an EPEL
9 specific file, we put them in a bad position. They would essentially be
forced to pick the least bad solution:
a) divert the branches like they did for the package.cfg file in epel8¹
b) put the file to Fedora branches, essentially disabling mass rebuilds
c) not opt out from building and deal with the rebuilds later by release bumps
And I think all three options either generate unnecessary work or have other
consequences.
¹ IIRC this was a huge 🥙 for packagers trying to use a single branch for
Fedora and EPEL 8.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
