Colin Walters <walters <at> verbum.org> writes:
> The problem I'm trying to solve is when people collaboratively
> maintain a package, you want to know when e.g. updating to a new
> upstream version what the upstream status of patches are so you know
> whether to expect to see them in the new tarball.
Why do you want to make this mandatory then? Some packages have only one
maintainer, some have multiple maintainers who have managed to handle this
issue just fine.
It's fairly easy anyway to figure out whether a patch has already been applied
upstream: try building with the patch, if it fails with "patch reversed or
already applied" in the build.log, drop the patch, make force-tag, resubmit.
That or directly check the upstream VCS. I'm going to have to do that anyway
because the comment above the patch might be outdated, e.g. in projects like
KDE where upstream may decide to backport a patch from trunk to the release
branch at any time (and as we obviously ship releases, not trunk snapshots,
what's on the release branch is what really matters, a "this has been
upstreamed in trunk and maybe some other branches" comment isn't very useful).
How we're currently handling this in the KDE packages is that we use patches
100 and above (with an "upstream patches" comment) for patches which come from
upstream and 0 to 99 for our own. However, the patches in 0 to 99 could have
been upstreamed since, and for the upstream patches, they could be coming from
any branch, so the usefulness for the use you're envisioning is limited.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
