Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
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. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100416204801.ga10...@rivendell
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Freitag, den 16.04.2010, 22:48 +0200 schrieb Raphael Hertzog: 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. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
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 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 `-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 johndoe-gu...@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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329104624.ga17...@master.debian.org
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog: 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). -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
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. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow: 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. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
On Mon, Nov 23, 2009 at 09:18:37AM +0100, Goswin von Brederlow wrote: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
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: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
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? 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
