Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
On Mon, Nov 23, 2009 at 04:26:21PM +0100, Goswin von Brederlow wrote:
> 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:
> >> > 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?
I'd also find this very useful. I mentioned it in
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-03-25-thoughts-on-3.0-quilt-format.html
before Raphaël pointed me at this thread.
> 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.
Yes, I agree we need both. (For instance, I forwarded a bunch of
patches just before OpenSSH 5.4p1 was released, many of which will be in
5.5p1; I plan to upload 5.4p1 soon, but would also like to annotate
which patches are in 5.5p1.)
I don't know that we need to bother with two fields, though. There's
precedent in DEP-3 for fields with internal structure; the format of
Origin is not dissimilar to what we need here. How about something like
the following?
Index: dep3.mdwn
===================================================================
--- dep3.mdwn (revision 142)
+++ dep3.mdwn (working copy)
@@ -178,6 +178,14 @@
This field can be used to record the date when the meta-information
was last updated. It should use the ISO date format `YYYY-MM-DD`.
+ * `Applied-Upstream` (optional)
+
+ This field can be used to document the fact that the patch has been
+ applied upstream. It may contain the upstream version expected to
+ contain this patch, or the URL or commit identifier of the upstream
+ commit (with commit identifiers prefixed with "commit:", as in the
+ `Origin` field), or both separated by a comma and a space.
+
Sample DEP-3 compliant headers
------------------------------
@@ -217,6 +225,15 @@
Bug-Debian: http://bugs.debian.org/265678
Author: Thiemo Seufer <ths@debian.org>
+A patch submitted and applied upstream:
+
+ Description: Fix widget frobnication speeds
+ Frobnicating widgets too quickly tended to cause explosions.
+ Forwarded: http://lists.example.com/2010/03/1234.html
+ Author: John Doe <johndoe-guest@users.alioth.debian.org>
+ Applied-Upstream: 1.2, http://bzr.example.com/frobnicator/trunk/revision/123
+ Last-Update: 2010-03-29
+
Related links
-------------
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: