Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Benjamin Drung <bdrung@ubuntu.com> writes:
> Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
>> Benjamin Drung <bdrung@ubuntu.com> writes:
>>
>> > Hi,
>> >
>> > When a new upstream version is released, I have to check all patches if
>> > they were accepted by upstream or not. I have to check each patch if I
>> > can drop it. It would make packaging new releases easier if there were
>> > an optional Applied-Upstream field. Every patch that was applied
>> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
>> > was not applied yet. If the patch was applied, it could contain the
>> > revision (like "r4681") or a link to the VCS commit.
>> >
>> > What do you think about my suggestion?
>>
>> Why would the source (or VCS head) ever contain a patch that was
>> applied upstream? The moment the patch gets applied you simply remove
>> it.
>
> Not until the next upstream release.
Sorry. Didn't quite grasp what you ment.
So what you want is (overly verbose)
Accepted-upstream: r1234 345836583468534854856834568395648
Will-Be-Obsolete-in: 1.2
while you still only have upstreams 1.1 in Debian.
I think the idea is good. The implementation seems to be in
doubt (where should it mention this, what should the field be called).
I would like to have both the information when it was commited and
when it will be released. The commit would be interesting because
often it differs from the debian patch to accomodate the newer
upstream developement. The release to know when the patch can be
removed.
MfG
Goswin
Reply to: