Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 08 2009, Ben Finney wrote: Paul Wise p...@debian.org writes: What format do the other DVCS systems use for patch export? Bazaar users generate a “merge directive” for serialising a change set URL:http://bazaar-vcs.org/MergeDirective. The merge directive is metadata to be read by the ‘bzr merge’ command; it is commonly accompanied in the same message by a plain-text ‘bzr diff’ output. That does not seem to be a good format for a patch scheme, since it is dependent on specialized code to implement it. Also, the git format-patch command can include encoded binary files, which I don't think patch(1) can handle. Right, all these serialisations are essentially supersets of what ‘patch(1)’ can do, since they include things like removing files etc. True. But our use case would still have a simple patch in the body; we are mostly talking about the header fields and the preamble in the body. Post the signature separator, the contents are still a simple patch. The resulting format is _compatible_ with git format-patch and git am, but not identical. Seems to me that we have a widely used convention (which might not be universal) that will meet our needs, and at least seems compatible with a lot of software under distributed version control. I think it well behooves us to re-use this, rather than go off an reinvent the wheel ourselves and be incompatible with _everything_ else out there. manoj -- No wife of *mine* is doing any dishes. That's what we had the kid for. from Deathlok comics #1 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Sep 09, 2009 at 08:50:34AM -0500, Manoj Srivastava wrote: Seems to me that we have a widely used convention (which might not be universal) that will meet our needs, and at least seems compatible with a lot of software under distributed version control. I think it well behooves us to re-use this, rather than go off an reinvent the wheel ourselves and be incompatible with _everything_ else out there. FWIW, for having discussed it with Raphael on #-qa, he seems pretty much convinced my proposal to make DEP3 compatible with git-format-patch is going in the good direction. He's annoyed I sent that mail so late (and FWIW sorry but I hadn't the time to do it before, and when I had time in august I hadn't connectivity.. but whatever) but I think the proposal will be amended so that we're compatible. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Sep 09, 2009 at 07:48:18PM +0200, Pierre Habouzit wrote: On Wed, Sep 09, 2009 at 08:50:34AM -0500, Manoj Srivastava wrote: Seems to me that we have a widely used convention (which might not be universal) that will meet our needs, and at least seems compatible with a lot of software under distributed version control. I think it well behooves us to re-use this, rather than go off an reinvent the wheel ourselves and be incompatible with _everything_ else out there. FWIW, for having discussed it with Raphael on #-qa, he seems pretty much convinced my proposal to make DEP3 compatible with git-format-patch is going in the good direction. He's annoyed I sent that mail so late (and FWIW sorry but I hadn't the time to do it before, and when I had time in august I hadn't connectivity.. but whatever) but I think the proposal will be amended so that we're compatible. Interestingly, using git format-patch format had been suggested back in june and july, with more opposition... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 8, 2009 at 7:53 AM, Pierre Habouzit madco...@madism.org wrote: On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. What format do the other DVCS systems use for patch export? Also, the git format-patch command can include encoded binary files, which I don't think patch(1) can handle. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 08, 2009 at 03:23:50PM +0800, Paul Wise wrote: On Tue, Sep 8, 2009 at 7:53 AM, Pierre Habouzit madco...@madism.org wrote: On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. What format do the other DVCS systems use for patch export? IIRC hg generates mails pretty much like git nowadays, and the `hg import` feature works mostly like git does: You can import a patch straight from a mail message. Even patches as attachments work (to use the body part, it must have type text/plain or text/x-patch). From and Subject headers of email message are used as default committer and commit message. All text/plain body parts before first diff are added to commit message. I'm not used to bzr at all, but I would be surprised it does sth _very_ different. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
Paul Wise p...@debian.org writes: On Tue, Sep 8, 2009 at 7:53 AM, Pierre Habouzit madco...@madism.org wrote: On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. […] That's because those projects are in the special case of also using Git. Despite its popularity, Git is far from the only DVCS in common use. What format do the other DVCS systems use for patch export? Bazaar users generate a “merge directive” for serialising a change set URL:http://bazaar-vcs.org/MergeDirective. The merge directive is metadata to be read by the ‘bzr merge’ command; it is commonly accompanied in the same message by a plain-text ‘bzr diff’ output. Also, the git format-patch command can include encoded binary files, which I don't think patch(1) can handle. Right, all these serialisations are essentially supersets of what ‘patch(1)’ can do, since they include things like removing files etc. -- \“We should be less concerned about adding years to life, and | `\ more about adding life to years.” —Arthur C. Clarke, 2001 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Sat, 05 Sep 2009, Guido Günther wrote: I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. Would it be helpful to say that From: can be an alias for Author: and Subject: an alias for Description:? git format-patch alone will stil not be enough to generate a DEP3-compliant header but would that resolve your concerns? Is that really better over (auto-)duplicating those fields when needed? Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
+1 for SCM compatibility. Since version control is a best practice for packaging IMHO, I think we should be able to apply those processes cleanly enough to let us continue with them. When we import patches from upstream, I think most adhere to some kind of format, what is standard is where the patch came From: and what's it's Subject:. When we export patches too. What I think is that an alias would do the work. Since I've been maintaining a patches branch just for adding metadata, given the fact I'm using tg2quilt, as many of us are, I think it's an unnecessary pain. That's only my considerations, but hope made a point. On Mon, 2009-09-07 at 22:30 +0200, Raphael Hertzog wrote: On Sat, 05 Sep 2009, Guido Günther wrote: I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. Would it be helpful to say that From: can be an alias for Author: and Subject: an alias for Description:? git format-patch alone will stil not be enough to generate a DEP3-compliant header but would that resolve your concerns? Is that really better over (auto-)duplicating those fields when needed? Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. Cheers, -- Raphaël Hertzog -- Best regards, Adrian Perez adrianperez@gmail.com signature.asc Description: This is a digitally signed message part
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
Julien Cristau a écrit : FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. +1 -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: On Sat, 05 Sep 2009, Guido Günther wrote: I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. I missed that thread earlier and reacted to the dda mail in 20090907234314.ge13...@artemis.corp Would it be helpful to say that From: can be an alias for Author: and Subject: an alias for Description:? I made a full proposal for header fixes to be git/hg/... compatible. git format-patch alone will stil not be enough to generate a DEP3-compliant header but would that resolve your concerns? It will be compatible if you relax the use of headers to pseudo headers, and forget about your (sorry) ridiculous request for Description to be a rfc822 formatted field. Not only it's never used by anyone, but it's also a major PITA to edit. Like I said in my other mail, you want a Subject as a summary, and what you call Description is all that: - isn't a header - isn't a recognized pseudo-header - is before the patch or an optional ---\n line. It's a pretty simple definition, rather simple to implement in any kind of patch parsing tool. Indeed it's not compatible with grep-dctrl or whatever, but sadly for you, there _IS_ a standard for patches already, and it looks like that: - http://lkml.org/lkml/2009/8/31/369 - http://lkml.org/lkml/2009/8/31/40 - http://article.gmane.org/gmane.comp.version-control.git/126207 - http://article.gmane.org/gmane.comp.parsers.sparse/2001 - and I could go on with wine, x.org, gnome, ... patch submissions... damn even the glibc nowadays ! Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Mon, Sep 07 2009, Pierre Habouzit wrote: On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote: git format-patch alone will stil not be enough to generate a DEP3-compliant header but would that resolve your concerns? It will be compatible if you relax the use of headers to pseudo headers, and forget about your (sorry) ridiculous request for Description to be a rfc822 formatted field. Not only it's never used by anyone, but it's also a major PITA to edit. Like I said in my other mail, you want a Subject as a summary, and what you call Description is all that: - isn't a header - isn't a recognized pseudo-header - is before the patch or an optional ---\n line. It's a pretty simple definition, rather simple to implement in any kind of patch parsing tool. Indeed it's not compatible with grep-dctrl or whatever, but sadly for you, there _IS_ a standard for patches already, and it looks like that: - http://lkml.org/lkml/2009/8/31/369 - http://lkml.org/lkml/2009/8/31/40 - http://article.gmane.org/gmane.comp.version-control.git/126207 - http://article.gmane.org/gmane.comp.parsers.sparse/2001 - and I could go on with wine, x.org, gnome, ... patch submissions... damn even the glibc nowadays ! Anyway, I'd rather wait some time until people have tried using this format before deciding if we must make some special case due to git format-patch. It's not a special case. Kernel people, git people, gnome people, X.org people, all can cherry-pick patches and format-patch them away. If you ask them to add one missing header like the actual source or commid-id they took the patch from, they'll probably do it (I would at least). If you ask to rewrite the full stuff, then really, go to hell will probably be the (sane) answer you'll get. (Adding SELinux mailing lists where git format-patch rules). I think that git format-patch format seems to be emerging as a de facto standard for interchanging changesets, and if we are to create a new standard, we should stick close to ones that exist and are popular, and only differ from that if there is a compelling reason to be different. Is there a compelling reason to differ from what git format-patch and git am already use? manoj -- Every year a few research results pay the freight for all the rest. Robert A. Frosch, General Motors Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 01, 2009 at 07:32:55PM +0200, Julien Cristau wrote: On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote: Hello, I made some last changes to the DEP following round 4. You'll find them below. I plan to switch the DEP's status to CANDIDATE since it's about time to start using this new format to try it out. Once I've done this, I'll announce it on d-d-a to encourage people to start using it. Current version: http://dep.debian.net/deps/dep3/ FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, 01 Sep 2009, Julien Cristau wrote: On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote: Current version: http://dep.debian.net/deps/dep3/ FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. IMO that's fine for now, maybe someone will write a wrapper around git format-patch to auto-generate the correct headers while still keeping those needed for compatibity with git am / send-email. Are those patches in that format because you took them from the upstream git repository or because using this format from the start lets upstream pick it up easily? 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Sep 2, 2009 at 09:22:30 +0200, Raphael Hertzog wrote: Are those patches in that format because you took them from the upstream git repository or because using this format from the start lets upstream pick it up easily? Both (usually the latter though, because for patches which are already upstream I tend to use cherry-pick to apply directly, so they don't go through debian/patches/). Or because they're stolen from the fedora package, which iirc uses git to generate/apply patches. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote: Hello, I made some last changes to the DEP following round 4. You'll find them below. I plan to switch the DEP's status to CANDIDATE since it's about time to start using this new format to try it out. Once I've done this, I'll announce it on d-d-a to encourage people to start using it. Current version: http://dep.debian.net/deps/dep3/ FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
Julien Cristau wrote: On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote: Hello, I made some last changes to the DEP following round 4. You'll find them below. I plan to switch the DEP's status to CANDIDATE since it's about time to start using this new format to try it out. Once I've done this, I'll announce it on d-d-a to encourage people to start using it. Current version: http://dep.debian.net/deps/dep3/ FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. But random joe will not see those in your patch when they download the debian source. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 1, 2009 at 17:21:28 -0400, Felipe Sateler wrote: Julien Cristau wrote: FWIW, I'm not going to use something that I can't produce with git format-patch and feed to git send-email / git am since that feels like busy work; in particular the Author and Description fields are not needed given there's From and Subject with the same information. But random joe will not see those in your patch when they download the debian source. Yes they will [0,1]. [0] http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/fedora-vboxvideo.diff;h=fec7116d1c085562d0bab1e181efd2e6dcaa869e;hb=HEAD [1] http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/Turn-on-ModeDebug-by-default.patch;h=463e1f12534e7ecfbd72453913f47fb45dd833d2;hb=HEAD -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Thu, 27 Aug 2009, Paul Wise wrote: On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmanngre...@debian.org wrote: I prefer to omit Origin and interpret a missing-Origin-with-Author-present as a Debian patch. Adding a URL (pointing where - to a webinterface of a VCS?) seems cumbersome, and just stating in some way that the origin is Debian or the person who wrote the patch/put in into the package seems like a duplication of information and effort. I disagree, imagine the situation where Fedora imports some patches from Debian and then the Debian maintainer looks at Fedoras patches. In that case I, as the Debian maintainer would want to know which patches come from Debian so I can ignore them or check if they are modified from Debian. Ideally Fedora adds the missing URL in the Origin field since they also want to be able to verify what happened to the patch. Maybe that expectation should be documented in the DEP. 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Thu, Aug 27, 2009 at 01:23:40PM +0800, Paul Wise wrote: On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmanngre...@debian.org wrote: On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote: On Wed, 26 Aug 2009, Ben Finney wrote: I think that either of ‘Origin: vendor’ (for a patch created by the package maintainer) or ‘Origin: other’ would be better than omitting the field. I'd like to see the examples recommend its use in these cases. I don't share this opinion, let's see if we can have some more feedback. I prefer to omit Origin and interpret a missing-Origin-with-Author-present as a Debian patch. Adding a URL (pointing where - to a webinterface of a VCS?) seems cumbersome, and just stating in some way that the origin is Debian or the person who wrote the patch/put in into the package seems like a duplication of information and effort. I disagree, imagine the situation where Fedora imports some patches from Debian and then the Debian maintainer looks at Fedoras patches. In that case I, as the Debian maintainer would want to know which patches come from Debian so I can ignore them or check if they are modified from Debian. Relying on patch headers for that is the best way to get inaccurate information because other parties are pretty much likely to not modify the headers even when they modify the patch. Or remove them. Which means you still need to do the research, and the patch header is of no use for that. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, 26 Aug 2009, Ben Finney wrote: A minor point: If we're going to refer to the standard for these fields, then RFC 2822 is obsoleted by the current draft standard, RFC 5322 URL:http://tools.ietf.org/html/rfc5322. Shall we do this even if it's “only” a draft standard? +A patch created by the the Debian maintainer John Doe, which got forwarded +and rejected: + +Description: Use FHS compliant paths by default + Upstream is not interested in switching to those paths. + . + But we will continue using them in Debian nevertheless to comply with + our policy. +Forwarded: http://lists.example.com/oct-2006/1234.html +Author: John Doe j...@foobar.com +Last-Update: 2006-12-21 I would prefer if the ‘Origin’ field was recommended (or even required?) for every patch by this specification. What would an appropriate value for this field be in this example? Well, I'm not going to make it required when previous discussions lead to waive this requirement in specific cases (and this sample demonstrates such a case). Origin is best used with an URL and it's not always practical to provide one if you authored the patch and have not posted it anywhere. You could point to some VCS URL but you might not be able to know that URL before having commited the patch (in that case it's a chicken and egg problem). In the sample above, if I wanted to add the Origin field I would do something like this: Origin: vendor: written by maintainer, see Author 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
Raphael Hertzog hert...@debian.org writes: On Wed, 26 Aug 2009, Ben Finney wrote: A minor point: If we're going to refer to the standard for these fields, then RFC 2822 is obsoleted by the current draft standard, RFC 5322 URL:http://tools.ietf.org/html/rfc5322. Shall we do this even if it's “only” a draft standard? I'm not sure. The specific maturity levels of IETF standards (detailed in RFC 2026) give high importance to a Draft Standard, so the IETF demonstrate high confidence that RFC 5322 will become a standard and recommend serious production-level implementation of it. On the other hand RFC 5322 isn't yet assigned a STD number, and STD 11 is still associated with RFC 2822. I would prefer if the ‘Origin’ field was recommended (or even required?) for every patch by this specification. What would an appropriate value for this field be in this example [where the patch originates with the Debian package maintainer and exists only in the package]? Well, I'm not going to make it required when previous discussions lead to waive this requirement in specific cases (and this sample demonstrates such a case). Fair enough, I'm not about to open that up again. I see that the current draft says “required except if Author is present”, which meets my concerns adequately. Origin is best used with an URL and it's not always practical to provide one if you authored the patch and have not posted it anywhere. The absence of an ‘Origin’ field simply leads the reader to too many possible explanations, including “the writer of this patch header could have said where this patch came from but neglected to say”. In other words, I disagree with the current draft's assertion: If the Author field is present, the Origin field can be omitted and it’s assumed that the patch comes from its author. I think the ‘Origin’ field is important for being explicit about the provenance of the patch, even if its location online can't be pointed to by URL. In the sample above, if I wanted to add the Origin field I would do something like this: Origin: vendor: written by maintainer, see Author I think that either of ‘Origin: vendor’ (for a patch created by the package maintainer) or ‘Origin: other’ would be better than omitting the field. I'd like to see the examples recommend its use in these cases. -- \ “It is the mark of an educated mind to be able to entertain a | `\ thought without accepting it.” —Aristotle | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, 26 Aug 2009, Ben Finney wrote: In the sample above, if I wanted to add the Origin field I would do something like this: Origin: vendor: written by maintainer, see Author I think that either of ‘Origin: vendor’ (for a patch created by the package maintainer) or ‘Origin: other’ would be better than omitting the field. I'd like to see the examples recommend its use in these cases. I don't share this opinion, let's see if we can have some more feedback. While I would like to have the vendor|other info for stats purpose, discussions have made it clear that they are not worth the addition of a supplementary field. Furthermore, vendor and other were meant as prefix, which they are not in your samples. That would make another special case to explain. 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, Aug 26, 2009 at 01:56:35AM +0200, Raphael Hertzog wrote:
I made some last changes to the DEP following round 4. You'll find them below.
I plan to switch the DEP's status to CANDIDATE since it's about time to start
using this new format to try it out. Once I've done this, I'll announce it on
d-d-a to encourage people to start using it.
Current version: http://dep.debian.net/deps/dep3/
Thanks for giving a very good example of leading a DEP discussion!
I'd like to take this occasion to remind you all that
http://dep.debian.net has been revamped and that now contains both
more info about what DEPs are and a (hopefully) up to date index.
As a procedural heads up, please update also the index.mdwn file when
you switch the state of the DEP to CANDIDATE. [1]
Cheers
[1] for all the people wondering: no, we don't have yet a mechanism to
update automagically the index
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote: On Wed, 26 Aug 2009, Ben Finney wrote: I think that either of ‘Origin: vendor’ (for a patch created by the package maintainer) or ‘Origin: other’ would be better than omitting the field. I'd like to see the examples recommend its use in these cases. I don't share this opinion, let's see if we can have some more feedback. I prefer to omit Origin and interpret a missing-Origin-with-Author-present as a Debian patch. Adding a URL (pointing where - to a webinterface of a VCS?) seems cumbersome, and just stating in some way that the origin is Debian or the person who wrote the patch/put in into the package seems like a duplication of information and effort. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/ `-NP: Queen: Innuendo signature.asc Description: Digital signature
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmanngre...@debian.org wrote: On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote: On Wed, 26 Aug 2009, Ben Finney wrote: I think that either of ‘Origin: vendor’ (for a patch created by the package maintainer) or ‘Origin: other’ would be better than omitting the field. I'd like to see the examples recommend its use in these cases. I don't share this opinion, let's see if we can have some more feedback. I prefer to omit Origin and interpret a missing-Origin-with-Author-present as a Debian patch. Adding a URL (pointing where - to a webinterface of a VCS?) seems cumbersome, and just stating in some way that the origin is Debian or the person who wrote the patch/put in into the package seems like a duplication of information and effort. I disagree, imagine the situation where Fedora imports some patches from Debian and then the Debian maintainer looks at Fedoras patches. In that case I, as the Debian maintainer would want to know which patches come from Debian so I can ignore them or check if they are modified from Debian. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC round 5: DEP-3: Patch Tagging Guidelines
Hello, I made some last changes to the DEP following round 4. You'll find them below. I plan to switch the DEP's status to CANDIDATE since it's about time to start using this new format to try it out. Once I've done this, I'll announce it on d-d-a to encourage people to start using it. Current version: http://dep.debian.net/deps/dep3/ === Changes since last round === I waiwed the RFC-2822 compliancy requirement: -The meta-information would be stored in a set of RFC-2822 compliant -fields. Those fields should start on the first non-empty line (after -having stripped whitespace characters at the start and end of lines). +The meta-information would be stored in a set of RFC-2822-like +fields (the difference with RFC-2822 is that newlines are meaningful in +the Description field, they are not simple continuation characters). +Those fields should start on the first non-empty line (after having +stripped whitespace characters at the start and end of +lines). I added some samples: +Sample DEP-3 compliant headers +-- + +A patch cherry-picked from upstream: + +Description: Fix regex problems with some multi-bytes characters +Origin: upstream: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56ba +Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9697 +Bug-Debian: http://bugs.debian.org/510219 + +A patch created by the the Debian maintainer John Doe, which got forwarded +and rejected: + +Description: Use FHS compliant paths by default + Upstream is not interested in switching to those paths. + . + But we will continue using them in Debian nevertheless to comply with + our policy. +Forwarded: http://lists.example.com/oct-2006/1234.html +Author: John Doe j...@foobar.com +Last-Update: 2006-12-21 + +A vendor specific patch not meant for upstream submitted on +the BTS by a Debian developer: + +Description: Workaround for broken symbol resolving on mips/mipsel + The correct fix will be done in etch and it will require toolchain + fixes. +Forwarded: not-needed +Origin: vendor: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=80;bug=265678 +Bug-Debian: http://bugs.debian.org/265678 +Author: Thiemo Seufer t...@debian.org Comments welcome! 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
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
Raphael Hertzog hert...@debian.org writes: I plan to switch the DEP's status to CANDIDATE since it's about time to start using this new format to try it out. Once I've done this, I'll announce it on d-d-a to encourage people to start using it. Thanks for your ongoing work on this, I'm finding it useful. -The meta-information would be stored in a set of RFC-2822 compliant -fields. Those fields should start on the first non-empty line (after -having stripped whitespace characters at the start and end of lines). +The meta-information would be stored in a set of RFC-2822-like +fields (the difference with RFC-2822 is that newlines are meaningful in +the Description field, they are not simple continuation characters). A minor point: If we're going to refer to the standard for these fields, then RFC 2822 is obsoleted by the current draft standard, RFC 5322 URL:http://tools.ietf.org/html/rfc5322. -The meta-information would be stored in a set of RFC-2822 compliant -fields. Those fields should start on the first non-empty line (after -having stripped whitespace characters at the start and end of lines). +The meta-information would be stored in a set of RFC-5322-like +fields (the difference with RFC-5322 is that newlines are meaningful in +the Description field, they are not simple continuation characters). +Those fields should start on the first non-empty line (after having +stripped whitespace characters at the start and end of +lines). +Sample DEP-3 compliant headers +-- […] +A patch created by the the Debian maintainer John Doe, which got forwarded +and rejected: + +Description: Use FHS compliant paths by default + Upstream is not interested in switching to those paths. + . + But we will continue using them in Debian nevertheless to comply with + our policy. +Forwarded: http://lists.example.com/oct-2006/1234.html +Author: John Doe j...@foobar.com +Last-Update: 2006-12-21 I would prefer if the ‘Origin’ field was recommended (or even required?) for every patch by this specification. What would an appropriate value for this field be in this example? -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Wed,26.Aug.09, 01:56:35, Raphael Hertzog wrote: +A patch created by the the Debian maintainer John Doe, which got ^^^ Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
