Re: Patch metadata (Was: Plan for tomorrows (20080424) FESCO meeting)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux