Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Benjamin Drung
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?
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
Raphael Hertzog
On Mon, 23 Nov 2009, Benjamin Drung wrote:
> 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 suppose that you would want to add the field as soon as the patch is
committed upstream so that you can more easily identify patches to remove
when the next upstream version is out?
Do you expect to automate this operation?
I'm not sure we need a new field for this purpose, you could add a comment
in the description field or even change the Forwarded: URL to point to the
upstream VCS to make it clearer that it got merged.
Let's see what other people are thinking of it.
BTW, speaking of DEP-3, someone mentioned that it doesn't tell the
encoding to use. Does anyone oppose to adding a note saying that it
should aim at being ASCII-only and if that's not possible then UTF-8
should be used?
Cheers,
--
Raphaï¿œl Hertzog
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Benjamin Drung
> Hi,
>
> On Mon, 23 Nov 2009, Benjamin Drung wrote:
> > 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 suppose that you would want to add the field as soon as the patch is
> committed upstream so that you can more easily identify patches to
remove
> when the next upstream version is out?
Yes, indeed.
> Do you expect to automate this operation?
Adding the field would be manual, but removing the patches can do a
simple script, when the next upstream release is out.
> I'm not sure we need a new field for this purpose, you could add a
comment
> in the description field or even change the Forwarded: URL to point to
the
> upstream VCS to make it clearer that it got merged.
Automating the removal would be hard then.
> BTW, speaking of DEP-3, someone mentioned that it doesn't tell the
> encoding to use. Does anyone oppose to adding a note saying that it
> should aim at being ASCII-only and if that's not possible then UTF-8
> should be used?
I think that the DEP-3 header should be in UTF-8 (ASCII would be the
subset).
Goswin von Brederlow
> 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.
MfG
Goswin
Benjamin Drung
> Benjamin Drung <bdr...@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.
Mike Hommey
> Benjamin Drung <bdr...@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.
Ever heard of branches ?
Mike
Goswin von Brederlow
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.
Colin Watson
> Benjamin Drung <bdr...@ubuntu.com> writes:
> > Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
> >> Benjamin Drung <bdr...@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 <t...@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 <johndo...@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 [cjwa...@debian.org]
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100329104...@master.debian.org
Raphael Hertzog
sorry for the delay answering.
On Mon, 29 Mar 2010, Colin Watson wrote:
> 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?
Thanks for the suggestion, it looks good so I applied it.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100416204801.GA10791@rivendell
Benjamin Drung
> Hi,
>
> sorry for the delay answering.
>
> On Mon, 29 Mar 2010, Colin Watson wrote:
> > 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?
>
> Thanks for the suggestion, it looks good so I applied it.
Thanks.