On 14. 05. 21 17:20, Stephen Gallagher wrote:
On Fri, May 14, 2021 at 11:05 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
...
First of all: Thanks. This is what many of us wanted from the beginning
of ELN and this will allow us to crop many of our unwanted dependencies
for RHEL 10+, already in ELN.
An automation that cherry-picks (rather than merges) Rawhide changes
into ELN would be even more helpful. In Python Maint, we have some
semi-automatic tools ready; let me know in case you want to explore them.
If you've already got tools that can help with this, I'm all ears!
We use this to cherry pick commits or entire pull requests from
arbitrary components on src.fp.o to other branches/components/dist-gits:
https://github.com/fedora-python/ferrypick/blob/master/ferrypick.py
This (highly experimental) script can be used to create various backport
branches needed to create PRs (it is a wrapper around the script above):
https://github.com/fedora-python/branchsync
This merge driver can possibly help cherry-pick/merge commits that would
otherwise fail due to to %chaneglog problems:
https://github.com/encukou/rpm-spec-merge-driver
I however do have several concerns to discuss:
1) During the RHEL 9 development cycle, the process was more or less:
ELN -> Fedora 34 -> CentOS Stream 9
Do we assume similar concept for RHEL 10? I.e.:
ELN -> Fedora 40-ish -> CentOS Stream 10
If so, every change we make in ELN will be de-facto overridden by the
sync from Fedora branched and hence making changes in the ELN branch
will not help our RHEL-related work much. Or am I missing something?
Hmm, that is indeed an interesting question. I don't want to give an
off-the-cuff answer (it deserves more thought), but we *will* need to
address this. The time period in question (when Rawhide and the Fedora
we intend to branch from has diverged) is complicated. This time
around, we let ELN stay with Rawhide and used F34 as source for the
sync to EL9 until F34 Final Freeze, but indeed if some packages are
going to be tracked independently via an ELN branch, that gets...
trickier.
Of course, this time around we were also rushing to get the
infrastructure in place for CentOS Stream 9, which will already be
available for EL 10... so maybe the answer here is to just go directly
from ELN into CentOS Stream 10 at the Fedora 40 Branch point? It means
a bit more manual syncing from Fedora during that time period, but
that might not be too painful.
If the manual sync is easy (no bugzillas flags required), I would say
that is the way to go. It eliminates one extra "why is the workflow
changing every week" moment. It also no longer encourages the RHEL
maintains to push their changes to Fedora branched in the same time
windows when we try to stabilize it.
We have a couple years to think this through; thanks for bringing it up.
I agree that we don't need to to necessarily solve this right now.
2) Who opts in for the eln branch and who is responsible for keeping it
up to date? For cases where the Fedora and RHEL maintainers are the same
people, it is obviously them. But what about other cases? E.g.:
1. Fedora maintainer of package foo refuses RHEL-only changes.
2. RHEL maintainer of foo requests an eln branch.
3. Fedora maintainer frequently updates foo in Rawhide.
4. RHEL maintainer does not care about foo in Fedora for 2 years.
5. The package in ELN is much older than the Rawhide one.
I think this could be solved by policy. Something like "If the eln
branch is neglected (needs to be well defined), the package switches
back to the rawhide branch."
I think we can make the policy super-simple: every package on ELN gets
forcibly re-synced to Rawhide on the day we fork to CentOS Stream.
Each new major release reset, we require them to request to diverge
the sync again.
That sounds really harsh towards the maintainers who actually do keep
the eln branch up to date all the time. We would wipe their changes
every 3 years, and they would need to reintroduce them again.
3) Similarly, assume foo has opted in for an eln branch. The Fedora
packager maintainer walks away and foo is adapted by another maintainer
who wants to maintain %if-spaghetti rather than 2 distinct branches. How
do they opt out? Do we "archive" the eln branch until it is requested
again? Or do we merge rawhide and eln branches, sot hey have the same
HEAD and than turn eln into a symbolic reference?
I think archiving the ELN branch is probably the simplest approach
here. All we need to do is flip the auto-rebuild configuration back
over to stop excluding the package and the next Rawhide build will
trigger an ELN build again.
However, when looking at the package source, it should be really obvious
that the eln branch is no longer used for ELN. Otherwise it will be very
confusing for people who want to contribute.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
