FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-23-2009, 02:26 PM
Goswin von Brederlow
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-29-2010, 10:46 AM
Colin Watson
 
Default 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]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100329104624.GA17135@master.debian.org">http://lists.debian.org/20100329104624.GA17135@master.debian.org
 
Old 04-16-2010, 08:48 PM
Raphael Hertzog
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416204801.GA10791@rivendell">http://lists.debian.org/20100416204801.GA10791@rivendell
 
Old 04-16-2010, 09:41 PM
Benjamin Drung
 
Default 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)
 

Thread Tools




All times are GMT. The time now is 10:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org