As we have done since 5.15, we have done this again for os-build, we expect
to keep it up as a cadence with every upstream release. This means we
will do it again when 7.3 releases, and again with 7.4... It is
difficult to manage a regularly rebased tree, because any outstanding
MR is invalidated and has to also be rebased. But not doing somewhat
regular rebases can also be difficult in the spirit of the openness
that Fedora is based upon. While there are plenty of ways to see
which patches we carry compared to upstream, some of those patches are
fairly old, and would not apply cleanly at all to a modern tree after
several releases were merged in with them. As we have gotten into a
flow of things with merge requests, we can get to the point of very
few outstanding MRs towards the end of a release cycle, and that makes
it an opportune time to rebase the tree. This also means that the
patches we carry should be no more than 1 release out of date, making
them easier to apply to various other trees. I do realize that this
is a minor inconvenience every 2-3 months, but I believe the results
are worth it.
Thanks,
Justin
