Re: Patch Tagging Guidelines (aka DEP3)
On Wed, 23 Sep 2009, Kurt Roeckx wrote: For elfutils, I have 2 patches that I take from the upstream git repo. Both patches have their own branch, and upstream/redhat merges the master branch into them. So around the time of an upstream release I do git diff release...branch to get the new patch. Those branches contain several patches, so it's not a single commit. And I'm not sure how to properly put in the header where it comes from. I would suggesto to put an URL pointing to a branch instead of pointing to a specific commit. And explain in the description how the patch was generated. 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: Patch Tagging Guidelines (aka DEP3)
On Tue, Sep 29, 2009 at 11:25:17AM +0200, Raphael Hertzog wrote: On Wed, 23 Sep 2009, Kurt Roeckx wrote: For elfutils, I have 2 patches that I take from the upstream git repo. Both patches have their own branch, and upstream/redhat merges the master branch into them. So around the time of an upstream release I do git diff release...branch to get the new patch. Those branches contain several patches, so it's not a single commit. And I'm not sure how to properly put in the header where it comes from. I would suggesto to put an URL pointing to a branch instead of pointing to a specific commit. And explain in the description how the patch was generated. That assumes you can point to a URL. It might have a public VCS repo, but not some website. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote: You are welcome to share your feedback about this format on -devel, if we identify shortcomings or possible enhancements, we can still update the proposal (but only after we had time to get some real feedback based on actual usage of this format). For elfutils, I have 2 patches that I take from the upstream git repo. Both patches have their own branch, and upstream/redhat merges the master branch into them. So around the time of an upstream release I do git diff release...branch to get the new patch. Those branches contain several patches, so it's not a single commit. And I'm not sure how to properly put in the header where it comes from. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
Hi, On Tue, 08 Sep 2009, Matthijs Kooijman wrote: Just a small inconsistency I noted. The description for Origin says The field can be optionaly prefixed with a single keyword followed by a comma and a space to categorize the origin. while the examples use a colon instead of a comma: Indeed, fixed, thanks for telling me. On Tue, 08 Sep 2009, Bjørn Mork wrote: Raphael Hertzog hert...@debian.org writes: after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ Just a minor comment on the examples: Please either use your own domain names or one of the names reserverd for examples. foobar.com is registered to Foobar Consulting. They're probably used to this kind of abuse, but still... Fixed too, I was already using example.com for a fake URL and I needed another different domain for the author. I used a Debian one, now. 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: Patch Tagging Guidelines (aka DEP3)
Raphael Hertzog hert...@debian.org writes: On Tue, 08 Sep 2009, Bjørn Mork wrote: Just a minor comment on the examples: Please either use your own domain names or one of the names reserverd for examples. foobar.com is registered to Foobar Consulting. They're probably used to this kind of abuse, but still... Fixed too, I was already using example.com for a fake URL and I needed another different domain for the author. I used a Debian one, now. Better than using a Debian one, you can make use of any or all of ‘example.com’, ‘example.org’, ‘example.net’. Each of those is guaranteed available for use in examples by RFC 2606, and the fact that there are three separate domains gives you flexibility in choosing examples. -- \ “To succeed in the world it is not enough to be stupid, you | `\must also be well-mannered.” —Voltaire | _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: Patch Tagging Guidelines (aka DEP3)
Raphael Hertzog hert...@debian.org writes: after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ Just a minor comment on the examples: Please either use your own domain names or one of the names reserverd for examples. foobar.com is registered to Foobar Consulting. They're probably used to this kind of abuse, but still... See RFC 2606 for some names that can be used. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
Hi all, after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ Just a small inconsistency I noted. The description for Origin says The field can be optionaly prefixed with a single keyword followed by a comma and a space to categorize the origin. while the examples use a colon instead of a comma: Origin: upstream: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac; Gr. Matthijs signature.asc Description: Digital signature
Re: Patch Tagging Guidelines (aka DEP3)
On Mon, 07 Sep 2009, Raphael Hertzog wrote: after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ s/standard/standard proposal/ of course, if that was not clear by the fact that it's only at state “CANDIDATE“. Sorry for the mistake. 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: Patch Tagging Guidelines (aka DEP3)
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote: after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ at a quick look this again seems to have degenerated in lots of Debianism: * Why using Description for subject? Author instead of From.. * Why not reqesting the patches to be git am appliable. this way quilt understands them, they can be easily be bounced of to upstream thanks to existing tools. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote: Hello, after several rounds of discussion on -devel, we now have a new standard defining meta-information to integrate on patches that we distribute/apply in our packages: http://dep.debian.net/deps/dep3/ Sorry I haven't answered to the DEP before, but I've been pretty busy so far. FWIW I don't like it completely because it's not compatible with the de-facto standard used by kernel-like project (that would count linux, or git, and many other). In git (and the idea is trivially used in any VCS that can format-patch to mail) you use either rfc822 headers or pseudo-headers for many fields you have re-defined. My point is that there are _lots_ of patches that follow the kernel conventions out there, and it should not require anything more than grabbing the patch, possibly add an URL in it pointing to where you grabbed it from, and be done with it. Your proposal requires an extensive rewrite of such patches, and it kind of sucks. Also I would like to be able to extract my patches from my git repository just doing a git format-patch upstream..upstream+patches e.g., and not having to touch them (hence the need for pseudo-headers). Here are my remarks wrt individual fields: * Description/Subject: Description should just be any bit of rfc822 text that isn't a header nor a patch nor a pseudo header. What you propose for Description is just a major hassle for any people using git/hg/... And you should have a short description, as Subject:. The description should not be mandatory, the Subject should be. Also, if the patch contains a line with exactly ---\n, then all that follows, up to the diff is data that is _not_ part of the Description, and should be dropped (it's where git puts its diffstat, and this format has also become a standard nowadays too). * From should be an allowed synonym for Author (git uses both, with a preference for From). * Reviewed-by is usually rather Acked-by. * Forwarded as a boolean (no/not-needed/...) field is IMHO useless, but whatever. Also, when the argument is an email address, Cc: is usually preferred. * Instead of Last-Update, simply Date: is usually preferred. Plus the proposed format is all but an iso standard. rfc822 dates are a better idea. Your proposal doesn't explicit what repetition of fields means. Debian usually uses: Foo: value1, value2, value3, ... But git people usually use: Foo: value1 Foo: value2 ... Both should be accepted and understood in the same way. Finally, I would suggest that Author or From should be mandatory for conforming patches, rather than Origin. And I would suggest a License: field for people wishing to license their patch with a specific license. FWIW, I don't believe any packager with an upstream using git will consider adopting DEP3 without those fixes. With those fixes though, it's just a tiny bit of effort for them, so you'll instead probably see quite a fast adopting rate for DEP3... -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
