Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
Le Mon, Aug 10, 2009 at 10:58:04AM -0400, Jonathan Yu a écrit : On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). Hi Jonathan, I pushed the logic further and taking advantage of the draft machine-readable format for debian/copyright, which in the absence of other mention assumes that the copyright statement applies to all files (implicit ‘Files: *’ field), I removed mentions about debianization and copyright for my packaging work. This effectively releases my work under ‘same as upstream’ conditions. It still leaves uncertainties in case of upstream relicensing, which is why I am also tempted by politically correct versions of the WTFPL, like the BOLA license: http://blitiri.com.ar/p/bola/ Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
Hi Charles: On Tue, Aug 18, 2009 at 3:06 AM, Charles Plessyple...@debian.org wrote: Le Mon, Aug 10, 2009 at 10:58:04AM -0400, Jonathan Yu a écrit : On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). Hi Jonathan, I pushed the logic further and taking advantage of the draft machine-readable format for debian/copyright, which in the absence of other mention assumes that the copyright statement applies to all files (implicit ‘Files: *’ field), I removed mentions about debianization and copyright for my packaging work. This effectively releases my work under ‘same as upstream’ conditions. I think it would be better to copy the stanza, and drop a note that you'd like the same as upstream conditions. I'm not entirely sure if one can make that assumption, since Files: applies to most files (usually only upstream ones) and debian/* ones will be copyright their authors with all rights reserved unless they say otherwise (per the Berne Convention). It still leaves uncertainties in case of upstream relicensing, which is why I am also tempted by politically correct versions of the WTFPL, like the BOLA license: http://blitiri.com.ar/p/bola/ Don't get me wrong, I really like the BOLA. Actually I've collaborated with Alberto Bertogli on a few things and I think that the License Agreement (though it really isn't much of a license at all) is pretty nicely written, especially since he's not a lawyer (and just a humble open source developer). My concern with BOLA and Public Domain in general is that some jurisdictions may not recognize it, though that is usually remedied with a statement like (lifted from one of my modules): I, the copyright holder of this package, hereby release the entire contents therein into the public domain. This applies worldwide, to the extent that it is permissible by law. In case this is not legally possible, I grant any entity the right to use this work for any purpose, without any conditions, unless such conditions are required by law. It might be enough that Alberto is a nice guy and I doubt he'd pursue legal action for his software; but nonetheless it's a concern (maybe just FUD though). This is an interesting article about public domain, including issues like copyright vs author's rights in Germany: http://www.edwardsamuels.com/copyright/beyond/articles/public.html I should mention I'm not a lawyer. I'm not all too concerned with copyright personally, though I do agree it's important to make sure everything we put in the main archive is DFSG-free. I have chosen to release a few of my things as Public Domain OR MIT OR (Same terms as Perl = GPL | Artistic). Note these are Perl modules I'm releasing, so in the case where there is no notion of Public Domain/disclaimed copyright, people can use it under the very permissive MIT license, or the Perl-compatible dual license scheme. What's wrong with just assigning debian/* to same terms as upstream? -- that way, upstream will be able to integrate your changes at will. I guess one key is communicating effectively with upstream authors (better yet, being the upstream author). They don't really *need* copyright on debian/ files -- the only questionable part is in the d/patches/* files, and I'm not really sure how copyright works for patches :-) Oh, another problem with public domain is that it's not a license, so there isn't a standard text in common-licenses you can refer to. That means larger copyright files, which means larger packages (though only a few KB). Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
On Tue, Aug 11, 2009 at 9:56 PM, Romain Beauxisto...@rastageeks.org wrote: Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit : On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? Dear all, we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). So for example if upstream is BSD-licensed, then I'd personally put something like: Artistic | GPL | BSD for the debian/* files My reasoning is that the upstream can get stuff like patches back into their software (the BSD) provision but also allows anyone that can use Perl to use the patch (Artistic | GPL). Further, if upstream decides later to change to the same as Perl license (it is probably the most popular license on CPAN), it is okay for them to do so (with our patches). In the case of Debian-Med (being an outsider and not knowing what the team works with), I'd say explicitly licensing your debian/* files under the same license as upstream would be appropriate, or perhaps a combination of upstream | GPL licensing. This is clearly a discussion we all need to have within teams/package groups/etc -- namely, what do we want our debian/* files to be licensed under. And also what exactly is covered by the license claim. For instance, in the case of patches contained in debian/, I have some doubts about the license that applies. Usually, when one wants to propose a patch to a project, it has to do it under the original licence. That's particularly the case if the patch consists, for instance, of the diff of a commit from the current developpement code of the same upstream project... That does apply if you are proposing a patch for direct inclusion into the project, though not even necessarily. I think that in that case it's usually just assumed that you are providing code under the same license. With a patch you're writing original code so you should have the right to license it as you please, but you still need for the patch to comply with the original license so that it can be included without forcing upstream to change their license. In any case, some superset of upstream + whatever other licenses you want should be OK, since the upstream can integrate your changes by licensing the code under their license. You still technically hold the copyright to the diff but it usually doesn't matter, and authors often assume copyright of your work unless it's a rather sizable patch, which I think is what we want in the end. Anyway, if the patch is applied upstream it's usually removed from debian/patches/* so this point is sort of moot, right? As long as the upstream is allowed to integrate the patch Hence, are patches in debian/ covered by the license claimed for the project upstream, or for the debian packaging ? I'm of course not a lawyer, but my assumption is that code written by someone is owned by that person, so it's covered by the Debian packager/packaging team. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit : On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? Dear all, we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). So for example if upstream is BSD-licensed, then I'd personally put something like: Artistic | GPL | BSD for the debian/* files My reasoning is that the upstream can get stuff like patches back into their software (the BSD) provision but also allows anyone that can use Perl to use the patch (Artistic | GPL). Further, if upstream decides later to change to the same as Perl license (it is probably the most popular license on CPAN), it is okay for them to do so (with our patches). In the case of Debian-Med (being an outsider and not knowing what the team works with), I'd say explicitly licensing your debian/* files under the same license as upstream would be appropriate, or perhaps a combination of upstream | GPL licensing. This is clearly a discussion we all need to have within teams/package groups/etc -- namely, what do we want our debian/* files to be licensed under. And also what exactly is covered by the license claim. For instance, in the case of patches contained in debian/, I have some doubts about the license that applies. Usually, when one wants to propose a patch to a project, it has to do it under the original licence. That's particularly the case if the patch consists, for instance, of the diff of a commit from the current developpement code of the same upstream project... Hence, are patches in debian/ covered by the license claimed for the project upstream, or for the debian packaging ? Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? Dear all, we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). So for example if upstream is BSD-licensed, then I'd personally put something like: Artistic | GPL | BSD for the debian/* files My reasoning is that the upstream can get stuff like patches back into their software (the BSD) provision but also allows anyone that can use Perl to use the patch (Artistic | GPL). Further, if upstream decides later to change to the same as Perl license (it is probably the most popular license on CPAN), it is okay for them to do so (with our patches). In the case of Debian-Med (being an outsider and not knowing what the team works with), I'd say explicitly licensing your debian/* files under the same license as upstream would be appropriate, or perhaps a combination of upstream | GPL licensing. This is clearly a discussion we all need to have within teams/package groups/etc -- namely, what do we want our debian/* files to be licensed under. This reminded me of this thread and I filled the bug #540740. (Note that it is not only about patches, but all the other possible contributions: documentation, artwork,…) Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? Dear all, we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. This reminded me of this thread and I filled the bug #540740. (Note that it is not only about patches, but all the other possible contributions: documentation, artwork,…) Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Fri, Jul 17, 2009 at 06:48:22AM -0400, David Bremner wrote: [..snip..] At least with topgit, patch branches are meant to be pushed and pulled, and use merge rather than rebase for just this reason. This makes the history ugly, but does facilitate the kind of collaboration James alluded to. I lost track of what the global point of this Sure. I think I do understand what James is talking about. It's basically a matter of taste if you rebase patch branches or use topgit - both have their up and downsides. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
a workflow based on rebasing? (was: RFC: DEP-3: Patch Tagging Guidelines)
also sprach Guido Günther a...@sigxcpu.org [2009.07.22.1523 +0200]: Sure. I think I do understand what James is talking about. It's basically a matter of taste if you rebase patch branches or use topgit - both have their up and downsides. With reference to http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2009-May/000616.html, I'd love to see a detailed account of your workflow. I am failing to wrap my head around how it would work and would appreciate being able to learn from you. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the word yellow wandered through his mind in search of something to connect with. -- hitchhiker's guide to the galaxy digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: RFC: DEP-3: Patch Tagging Guidelines
On Wed, Jul 08, 2009 at 07:24:20PM +0100, James Westby wrote: Guido Günther wrote: Which isn't a problem on patch-queue branches since you either can recreate them anytime from what's in debian/patches or simply ammend the commit. They're supposed to be rebased frequently anyway. Supposed? That's not true in my opinion. It would tend to be hostile to people who would like to collaborate on the patches wouldn't it? Isn't this a question on how you lay out your workflow? The patch-queue branches are basically a tool that eases managing patches that end up in debian/patches while retaining the merge capabilities of git (e.g. when forwarding to new upstream versions, etc.) so there's not even a need to push them into remote repos - you do have all the information on master to recreate the patch-queue branch at any time. -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
At Fri, 17 Jul 2009 09:00:50 +0200, Guido Günther wrote: On Wed, Jul 08, 2009 at 07:24:20PM +0100, James Westby wrote: Guido Günther wrote: Which isn't a problem on patch-queue branches since you either can recreate them anytime from what's in debian/patches or simply ammend the commit. They're supposed to be rebased frequently anyway. That's not true in my opinion. It would tend to be hostile to people who would like to collaborate on the patches wouldn't it? Isn't this a question on how you lay out your workflow? The patch-queue branches are basically a tool that eases managing patches that end up in debian/patches while retaining the merge capabilities of git (e.g. when forwarding to new upstream versions, etc.) so there's not even a need to push them into remote repos - you do have all the information on master to recreate the patch-queue branch at any time. At least with topgit, patch branches are meant to be pushed and pulled, and use merge rather than rebase for just this reason. This makes the history ugly, but does facilitate the kind of collaboration James alluded to. I lost track of what the global point of this subthread was, but I did think a bit about DEP-3 and topgit, and it seems not particularly problematic since there is some header file .topmsg that already contains subject/signed-off-by headers, and is inserted into the exported patches. I guess it should be not hard to to add more headers. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
hi raphael, On Wed, Jul 15, 2009 at 11:16:01PM +0200, Raphael Hertzog wrote: snip discussion regarding freetext description location How do you expect to recognize the real starting point for the fields? The freetext might contain text that look like field names at the start of a line... I don't think that requesting fields to be first in the patch file (except shebang lines) is a real burden for maintainers... What do others people think ? i should say that i don't feel incredibly strongly about this, i was merely postulating that supporting something in the form of possible description block blank line headers block wouldn't be so different than headers block blank line possible description block i.e.: while read_a_series_of_uninteruppted_lines_from_metainfo(): if block_is_all_headers(): process_headers() else append_to_description() but the more i think about it the more i think that it's not really worth the effort, and forcing at least *some* modicum of structure could arguably be a good thing anyway. snip discussion wrt reviewed by as single or split address/date fields Given that we can have multiple Reviewed-by fields, how would both fields be linked together? i should say that i also don't have a strong opinion on this either, i only commented because i thought that (a) having timestamps could be valuable and (b) using two fields/lines might seem more natural for reading and writing by humans. with regards to linking them together, i suppose it'd be a convention that the most recent reviewed date referred to the most recent reviewed by field. I think we should rather recommend to include a timestamp in the review itself (supplementary lines in the Reviewed-by field?). so instead of: Reviewed-By: Some Reviewing Person em...@address.here Reviewed-Date: date in some agreed format you suggest something like: Reviewed-By: Some Reviewing Person em...@address.here on date in some agreed format or in the case the user wanted to break into multiple lines: Reviewed-By: Some Reviewing Person em...@address.here on date in some agreed format that doesn't seem so bad... Is it important to be able to automatically extract that information or is that mainly for the maintainer's consumption? in an ideal world i'd say both (i.e. detecting stale review info). but there's also an extra manual step which wouldn't be addressed by either solution, for either the human or the automated script: has the patch been updated since it was reviewed?. it would require diving through the VCS and/or reading changelogs to determine if a patch was in the same state as when it was reviewed (i think trusting local stat(2) info on the file is not a good solution). or, since i've reached the bottom of the mail here, but still want to procrastinate doing any real work today, here's a thought that just bubbled up: what if the reviewed information included some kind of patch body checksum to determine whether a patch was modified? perhaps there could be a better way of saying it, but i'm thinking something along the lines of: Reviewed-By: Some Reviewing Person em...@address.here on date in some agreed format for md5sum where md5sum could be generated by taking the md5sum of the patch body with all leading metadata stripped, possibly using a small utility tool for the lazy[1]. in any case, an automated lintian check could then detect when a patch had such a field that was out of date. Of course i'm not convinced that it'd be so useful that people would actually *use* such a feature... sean [1] this still doesn't address anything wrt authenticity, it's only convenience information. signature.asc Description: Digital signature
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, 04 Jul 2009, sean finney wrote: I believe it's important to be able to know where the patch came from. I do think that knowing where the patch came from is very important, and one of the main driving rationales behind this proposal. but more than a URL or a revision/commit id, and something that might need to be kept up-to-date? what's the benefit of having it be in such a strict and machine readable format? what benefit will a parser provide us being able to figure this out over us just reading it ourselves? Distribution-wide statistics. But I agree that this benefit doesn't warrant that this categorization be made mandatory. So I suggest to make that prefix optional like you suggested: at the very least, could other be implied with the lack of this field? i.e., it seems much more natural to say Origin: http://blah/foo.html and allow the keywords like upstream to be used as optional sugar to add further information. Ok. Are you saying that you don't want Bug-Vendor but only Bug without any requirement to indicate the vendor ? I think it would be bad because it would not allow to differentiate the upstream bug url from the others. is there a benefit to differentiating in a machine readable way? if a human reads that, they should by context be able to tell which references the upstream (i.e. bugs.project.net), vs. debian (i.e. bugs.debian.org) vs some other vendor just by reading it. if there's a rationale, i think it should be included in the DEP to clarify why this is important. for example, is it so that the patch can be traded between distros with minimal fuss to the headers? Yes, and also upstream is the central reference so if we want to return/display a single bugtracker entry, we should be able to select the upstream one when available. Origin: Some User em...@fqdn okay, maybe that should be Author, but then why have an additional and duplicate field Origin: other, submitted by... requirement? Ok, let's make Origin optional when there's an Author field. On Wed, Jul 01, 2009 at 02:08:28PM +0200, Raphael Hertzog wrote: That said, supporting the patch as script case needs some trickery to be able to reuse existing parsers (stripping # before passing lines to the parser). But allowing invalid lines as comments in the middle will make it completely impossible to reuse standard parsers. what about allowing the freetext preceeding or following the fields, but specifying the fields are to be uninterrupted? normalizing that into something that you could throw at a standard parser is only a handful of lines of code at most, and if you're already doing some trickery wrt dpatch's '#' that's a pretty marginal cost. How do you expect to recognize the real starting point for the fields? The freetext might contain text that look like field names at the start of a line... I don't think that requesting fields to be first in the patch file (except shebang lines) is a real burden for maintainers... What do others people think ? On Fri, Jul 03, 2009 at 02:07:15PM +0100, Jon Dowland wrote: One thing I would like to see patch metadata help facilitate is patch review. At the moment the Reviewed-by header proposed would allow a tool to ensure at least two sets of eyeballs had seen a patch; however, patches can go stale. I think some chronological information is needed alongside the review. I propose a Last-Reviewed header to capture this information. seems reasonable... Given that we can have multiple Reviewed-by fields, how would both fields be linked together? I think we should rather recommend to include a timestamp in the review itself (supplementary lines in the Reviewed-by field?). Is it important to be able to automatically extract that information or is that mainly for the maintainer's consumption? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jul 07, 2009 at 12:56:26AM +0100, James Westby wrote: Guido Günther wrote: I am concerned that just allowing to use git-format-patch will result in people not making an effort to markup other metadata in DEP#3 format, like bug numbers or reviewers and leave those as free-form in the body. We can have Forwarded:, Origin:, Received-by: in this format as well, just like Signed-off-by: or Reviewed-by: or Thanks:. They are difficult to update though. Say we collaborate in a VCS on the same package, and you create a patch and upload it, and then I later forward it. I will then want to change the Forwarded: value in the patch, however this is in the commit message, so must I amend your commit in order to do that? Which isn't a problem on patch-queue branches since you either can recreate them anytime from what's in debian/patches or simply ammend the commit. They're supposed to be rebased frequently anyway. 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: DEP-3: Patch Tagging Guidelines
Guido Günther wrote: Which isn't a problem on patch-queue branches since you either can recreate them anytime from what's in debian/patches or simply ammend the commit. They're supposed to be rebased frequently anyway. Supposed? That's not true in my opinion. It would tend to be hostile to people who would like to collaborate on the patches wouldn't it? Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Guido Günther wrote: I am concerned that just allowing to use git-format-patch will result in people not making an effort to markup other metadata in DEP#3 format, like bug numbers or reviewers and leave those as free-form in the body. We can have Forwarded:, Origin:, Received-by: in this format as well, just like Signed-off-by: or Reviewed-by: or Thanks:. They are difficult to update though. Say we collaborate in a VCS on the same package, and you create a patch and upload it, and then I later forward it. I will then want to change the Forwarded: value in the patch, however this is in the commit message, so must I amend your commit in order to do that? Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Thu, Jun 18, 2009 at 02:38:47PM +0200, Guido Günther wrote: So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin (Author) are already there, some of them already being used by other tools (git-dch). Wouldn't it make sense to choose (or at least allow for) a format that's compatbile with what git-format-patch generates? Why not just fix/change git-format-patch (or create a git-format-debian-patch) to create a DEP#3 conforming header instead? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sun, Jul 05, 2009 at 01:27:16PM +0200, Michael Banck wrote: On Thu, Jun 18, 2009 at 02:38:47PM +0200, Guido Günther wrote: So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin (Author) are already there, some of them already being used by other tools (git-dch). Wouldn't it make sense to choose (or at least allow for) a format that's compatbile with what git-format-patch generates? Why not just fix/change git-format-patch (or create a git-format-debian-patch) to create a DEP#3 conforming header instead? The current format created by git-format-patch can just be fed to git-am again (which eases work on patch-queue branches) or be send as an email to upstream. We can of course convert from and to a DEP#3 compatible format but why not use something the rest of world uses for exchanging patches? 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: DEP-3: Patch Tagging Guidelines
On Sun, Jul 05, 2009 at 02:32:57PM +0200, Guido Günther wrote: We can of course convert from and to a DEP#3 compatible format but why not use something the rest of world uses for exchanging patches? It is not what the rest of the world uses; it is just what git uses. I am concerned that just allowing to use git-format-patch will result in people not making an effort to markup other metadata in DEP#3 format, like bug numbers or reviewers and leave those as free-form in the body. That's better than nothing, of course. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sun, Jul 05, 2009 at 02:54:33PM +0200, Michael Banck wrote: On Sun, Jul 05, 2009 at 02:32:57PM +0200, Guido Günther wrote: We can of course convert from and to a DEP#3 compatible format but why not use something the rest of world uses for exchanging patches? It is not what the rest of the world uses; it is just what git uses. It's what's used in emails when exchanging patches, it's not at all git specific. It's just that git has a convenient way to generate these. We're looking into using an RFC 2822 style format, why not something that can be directly used as a mail message. It makes exchanging patches simpler. I am concerned that just allowing to use git-format-patch will result in people not making an effort to markup other metadata in DEP#3 format, like bug numbers or reviewers and leave those as free-form in the body. We can have Forwarded:, Origin:, Received-by: in this format as well, just like Signed-off-by: or Reviewed-by: or Thanks:. 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: DEP-3: Patch Tagging Guidelines
Hi all, I take the opportunity of this discussion to make a few other questions and comments… Le Sat, Jul 04, 2009 at 12:35:16AM +0200, sean finney a écrit : Origin: Some User em...@fqdn okay, maybe that should be Author, but then why have an additional and duplicate field Origin: other, submitted by... requirement? By the way, it a patch originates from Debian, what should we write? ‘Origin: vendor : Debian’? Is it worth advising that lines be 80 characters (including Description: )? i'd say so, but only as a polite suggestion/reminder. In addition, it limits the short description to 80 - ‘Description: ’ = 67 characters. Le Sat, Jul 04, 2009 at 02:58:28AM +0200, gregor herrmann a écrit : Maybe I'm too lazy but I'd rather use Bug: #123456 Bug_CPAN: #12345 Note that for Sourceforge, it seems that more than one number is required. For instance, for the bug 1215086, only the second of the below URLs work: https://sourceforge.net/tracker/?func=detailaid=1215086 https://sourceforge.net/tracker/?func=detailaid=1215086group_id=133157atid=726404 Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Hi Charles On Sat, Jul 04, 2009 at 10:55:13PM +0900, Charles Plessy wrote: Le Sat, Jul 04, 2009 at 02:58:28AM +0200, gregor herrmann a écrit : Maybe I'm too lazy but I'd rather use Bug: #123456 Bug_CPAN: #12345 Note that for Sourceforge, it seems that more than one number is required. For instance, for the bug 1215086, only the second of the below URLs work: https://sourceforge.net/tracker/?func=detailaid=1215086 https://sourceforge.net/tracker/?func=detailaid=1215086group_id=133157atid=726404 Having only the bugnumber should work too, but the URL is then: https://sourceforge.net/support/tracker.php?aid=1215086 Hope that helps, Kind regards Salvatore signature.asc Description: Digital signature
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, Jul 4, 2009 at 10:05 PM, Salvatore Bonaccorsosalvatore.bonacco...@gmail.com wrote: Having only the bugnumber should work too, but the URL is then: https://sourceforge.net/support/tracker.php?aid=1215086 That can be further shortened to this: http://sf.net/support/tracker.php?aid=1215086 -- 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: DEP-3: Patch Tagging Guidelines
here's a nice big group-reply with an assortment of comments :) overall i think this looks pretty good, though i do have some concerns that will kind of repeat themselves below about there being too much emphasis on something machine friendly instead of human friendly... On Sun, Jun 21, 2009 at 12:07:42PM -0500, Raphael Geissert wrote: Raphael Hertzog wrote: Origin (required) Making this field mandatory doesn't sound like a good idea to me, as it ACK On Mon, Jun 29, 2009 at 10:03:24PM +0200, Raphael Hertzog wrote: On Sun, 21 Jun 2009, Raphael Geissert wrote: Description (required) Why not simply consider all the free-form text the description? that would make all the current patches with a comment insta DEP3-compliant. Done, but that's a recommendatino for the parser. Note that it's not DEP3-compliant since the Origin field is required. i really don't see why the origin field should be required, at least as is. personally i'd find the idea a bit cumbersome, as the same keyword information has probably been documented elsewhere (the changelog) and possibly duplicated (in the patch description), maybe even multiple times (the version control system), and possibly incorrect (a cherry-picked patch is updated locally due to other conflicting patches, but the header still implies otherwise because the maintainer forgot to update it). i'm also not sure i see the benefit in being able to know in an automated and machine readable way whether a patch was cherry-picked or backported or cross-ported or from an arbitrary vendor or other. so... why not just let it be a URL or textual description? Origin (required) Making this field mandatory doesn't sound like a good idea to me, as it already clashes a bit with the forwarded and author fields. If the Origin is upstream, then it doesn't need to be forwarded; and it doesn't cope very well with the idea of patches by some John Doe user. I believe it's important to be able to know where the patch came from. I do think that knowing where the patch came from is very important, and one of the main driving rationales behind this proposal. but more than a URL or a revision/commit id, and something that might need to be kept up-to-date? what's the benefit of having it be in such a strict and machine readable format? what benefit will a parser provide us being able to figure this out over us just reading it ourselves? (i'm not trying to be rhetorical i'm actually interested in hearing the justification) Bug-Vendor or Bug (optional) Like Paul Wise already said: it would be better to have a single field where the urls to the bug trackers can be specified. It doesn't only make it easier to find the final url, but it also requires zero extra maintenance/updates on the parsing tools just to know about another bug tracker. Paul did not say that, he simply told that he preferred URLs instead of bug numbers. also, it should be kept in mind that some upstreams do not have bug tracking systems at all, so the URL could very well be referencing a mailing list post or news update or similar. Are you saying that you don't want Bug-Vendor but only Bug without any requirement to indicate the vendor ? I think it would be bad because it would not allow to differentiate the upstream bug url from the others. is there a benefit to differentiating in a machine readable way? if a human reads that, they should by context be able to tell which references the upstream (i.e. bugs.project.net), vs. debian (i.e. bugs.debian.org) vs some other vendor just by reading it. if there's a rationale, i think it should be included in the DEP to clarify why this is important. for example, is it so that the patch can be traded between distros with minimal fuss to the headers? On Tue, Jun 30, 2009 at 08:49:21AM +0200, Raphael Hertzog wrote: * “Origin (required): This field should document the origin of the patch. It starts with a single keyword that can have the following standard values” I think that the rules are too hard to follow strictly. What if the patch is not from upstream but for backporting, for instance? That case is covered: « “backport” (in the case of an upstream patch that had to be modified to apply on the current version) » (see above question about benefit of strict Origin syntax) The rules are not hard and if you don't know you should default to other. We could make that explicit if really needed. at the very least, could other be implied with the lack of this field? i.e., it seems much more natural to say Origin: http://blah/foo.html and allow the keywords like upstream to be used as optional sugar to add further information. and what about Origin: Some User em...@fqdn okay, maybe that should be Author, but then why have an additional and duplicate field Origin: other, submitted by... requirement? later on, On Wed, Jul 01, 2009 at 02:08:28PM +0200, Raphael Hertzog wrote: That said, supporting
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sun, 21 Jun 2009, Raphael Geissert wrote: Description (required) Why not simply consider all the free-form text the description? that would make all the current patches with a comment insta DEP3-compliant. Done, but that's a recommendatino for the parser. Note that it's not DEP3-compliant since the Origin field is required. Origin (required) Making this field mandatory doesn't sound like a good idea to me, as it already clashes a bit with the forwarded and author fields. If the Origin is upstream, then it doesn't need to be forwarded; and it doesn't cope very well with the idea of patches by some John Doe user. I believe it's important to be able to know where the patch came from. I don't agree that it clashes with other optional fields, when it clashes the optional field can precisely be avoided... Bug-Vendor or Bug (optional) Like Paul Wise already said: it would be better to have a single field where the urls to the bug trackers can be specified. It doesn't only make it easier to find the final url, but it also requires zero extra maintenance/updates on the parsing tools just to know about another bug tracker. Paul did not say that, he simply told that he preferred URLs instead of bug numbers. Are you saying that you don't want Bug-Vendor but only Bug without any requirement to indicate the vendor ? I think it would be bad because it would not allow to differentiate the upstream bug url from the others. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: On Sat, 20 Jun 2009, Raphael Geissert wrote: All I see here is that the tools should be able to extract the information from the changelog, which often includes a bug number and other bits of information. I would say the opposite. Once you have created your patch you should be able to do ˝dch -a --patch debian/patches/fix_typo.patch” and it would create the changelog entry for you. (not that I use dch very often, but) okay, I see your point. Converting structured content in non-structured content is easy, the opposite is more difficult. But not impossible, this has been done before and I guess it will happen again in the future :) Back to the DEP... Description (required) Why not simply consider all the free-form text the description? that would make all the current patches with a comment insta DEP3-compliant. Origin (required) Making this field mandatory doesn't sound like a good idea to me, as it already clashes a bit with the forwarded and author fields. If the Origin is upstream, then it doesn't need to be forwarded; and it doesn't cope very well with the idea of patches by some John Doe user. Bug-Vendor or Bug (optional) Like Paul Wise already said: it would be better to have a single field where the urls to the bug trackers can be specified. It doesn't only make it easier to find the final url, but it also requires zero extra maintenance/updates on the parsing tools just to know about another bug tracker. Regarding other posts: +expected that tools like lintian will be modified to recommend adding +those information in patches. As the technical impact on package is null, Please do not decrease the usability of lintian even further. In linitan speak, this should be a pedantic tag at most. I will leave that up to lintian maintainers. Although strictly speaking I'm not a lintian maintainer, am the person who implemented it. In this case I'd say it should be severity: wishlist, pedantic is for things that are nice/better, but don't provide much or any benefit. It is as simple as: would you file a report to ask the maintainer to use the DEP3 format? I'd say yes, because it provides the following benefits: better structured documentation, allows automated tools to parse it and ... Would you file a report to ask the maintainer to remove the CVS directories from upstream's tarball? I'd say no, what benefit does it provide? none. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, 20 Jun 2009, Ben Finney wrote: Raphael Hertzog hert...@debian.org writes: Merging all those ideas, I suggest we drop Status/Commit/Patch and use the following format: Origin: upstream|backport|vendor|other : url-or-commit I'd still suggest having the extra information optional in the case of anything but “other”: Origin: upstream [ : url-or-commit ] Origin: backport [ : url-or-commit ] Origin: vendor [ : url-or-commit ] Origin: other: url-or-commit Well, if you read the spec, the URL-or-commit part is already optional. I don't think that making it mandatory for the other case is important. Anyone knows it's best if it's there... Forwarded: yes|no|not-needed|url-or-text Again, I'll warn against specifying “one of these keywords, or whatever you like” since that begs for collisions in future when trying to introduce new keywords. Contary to Origin, I believe the set of official value will never need to be expanded so I preferred the simplified syntax. I'm trying hard to not over-engineer the spec and make it really intuitive to follow. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Fri, 19 Jun 2009, Raphael Geissert wrote: I mean, often the patch name already says enough about it, at times patches are just trivial (a typo fix doesn't need four or five lines to be described), at times they are forwarded as soon as the new package is uploaded, at times they are $VCS commits from upstream. And mandating or even recommending to add all that documentation is useless in those, and probably more, cases. Have you tried to write the field for your cases? The spec is relatively light-weight even if it tries to support the more complicated case too. Description: Fix typo Origin: vendor Forwarded: yes Description: Fix foo in bar Origin: backport: commit:08bfa6f46f5eab33e1d608870cca71632d051ddf Description: Change splash image (debian-specific branding) Origin: vendor Forwarded: not-needed Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: Have you tried to write the field for your cases? The spec is relatively light-weight even if it tries to support the more complicated case too. Yes, and the examples I mentioned are/were real cases. Description: Fix typo Origin: vendor Forwarded: yes The thing is, if the patch is already called fix_typo.patch, and am already describing it in the changelog with a proper entry like * debian/patches/fix_typo.patch: Fix typo in the main menu: s/setings/settings I would actually be duplicating the description (the patch name being the short description, and the changelog entry the long description). The only piece of information that is missing is the forwarded field; hence my proposed simplification. Description: Fix foo in bar Origin: backport: commit:08bfa6f46f5eab33e1d608870cca71632d051ddf * debian/patches/fix_foo_in_bar.patch: Cherry-pick commit 08bfa6f46 by upstream to fix foo in bar. Description: Change splash image (debian-specific branding) Origin: vendor Forwarded: not-needed * debian/patches/change_splash_image.patch: Use a Debian-branded splash image instead of the Foo-branded version shipped by upstream. Thanks to John Doe f...@bar.tld for the art work. All I see here is that the tools should be able to extract the information from the changelog, which often includes a bug number and other bits of information. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, Jun 20, 2009 at 12:44:12PM -0500, Raphael Geissert wrote: Raphael Hertzog wrote: * debian/patches/fix_typo.patch: Fix typo in the main menu: s/setings/settings I would actually be duplicating the description (the patch name being the short description, and the changelog entry the long description). The only piece of information that is missing is the forwarded field; hence my proposed simplification. Part of the problem here is that the changelog isn't a particularly good place to document the source of the package - it's roughly similar to the situation with normal source code where you'd expect the code to be readable without the changelog to explain it. All I see here is that the tools should be able to extract the information from the changelog, which often includes a bug number and other bits of information. This would work adequately for trivial patches but is likely to have issues if the patch is more involved and needs revisions (for things like upstream changes or as part of making it mergeable). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, 20 Jun 2009, Raphael Geissert wrote: All I see here is that the tools should be able to extract the information from the changelog, which often includes a bug number and other bits of information. I would say the opposite. Once you have created your patch you should be able to do ˝dch -a --patch debian/patches/fix_typo.patch” and it would create the changelog entry for you. Converting structured content in non-structured content is easy, the opposite is more difficult. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 17/06/09 at 12:40 +0200, Raphael Hertzog wrote: Hello everybody, I'll try to do some new proposals based on your feedback. But first let me address the topic of the usefulness of the proposal. While there are currently no tools making use of this format, I can imagine many interesting usage for this information. It starts with the simple stats (how many debian specific patch do we use?) and goes on to providing a nice web interface where people can browse all patches: - check all non-forwarded patches and help forwarding them - let upstream developers browse all patches which are not backports - let other distributions check all patches which are not debian-specific In any case, it's a required step IMO if we want to increase the visibility of our patches and ensure they are better reviewed. It seems that for many people, the scope of this DEP is unclear. Will our packages be RC-buggy if we don't follow that tagging? Or is it only a recommended format? I think that this should be clarified. I personally think that this should be a best practice, strongly encouraged, but not something mandatory. We might want to move to something mandatory later, though. On Mon, 15 Jun 2009, Mark Brown wrote: On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: * `Signed-off-by` (optional) This field can be used to document the fact that the patch has been reviewed by one or more persons. It should list their names and emails in the standard format (similar to the example given for the `Origin` field), separated by commas if needed. For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. I started first with Reviewed-by and then thought that it was stupid to not reuse the name that is already vastly used for a similar purpose. What do other people think? I'm fine with both names. I prefer Reviewed-by. On Tue, 16 Jun 2009, Charles Plessy wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. I have no opposition against an optional License field. Can you try to word a description for it? On the other side, I'm also not convinced it's really useful... if a patch author wants some specific licence different from upstream's license, he should make that explicit in the patch itself when he adds his own copyright notice. Right. for your effort to unifiy the format. Personally, I do not mind changing our local format for the DEP3 format as long as we have one release cycle to do it. Some of our packages have a very slow turnover. There's no forced switch planned... it has not technical impact on the distribution, so I don't mind if not all packages are converted, after it's up to you to see if new lintian warnings annoy you enough or not to live with it. :) See my comment above about this. It should be added to the introduction of the DEP. Now I'll switch to the discussion about the Origin/Status/Patch fields. It seems that this set of fields is not as optimized as it could be. [...] I'm fine with what came out of this discussion. Also, from reading this i'm assuming that debian bugs would be identified by Bug(s)-Debian? that seems a bit unwieldly, esp given that there will likely be more references to debian bugs than upstream/cross-stream bugs. Maybe we should also add a special shorthand for Closes: #nnn or similar? My personal preference is that Debian gets Bug and there's a seperate Bug(s)-Upstream field, but maybe there are also arguments to the contrary? One of the goals is also to make it easier to share patches among distribution vendors. So I don't really like to make the format too much Debian-centric. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? Debian: could be considered a shorthand alias for Bug-Debian maybe? I guess that could also address the above issue that i mentioned. See my answer to Lucas. Well, you didn't answer my point: We could have Debian: for the Debian bug, and Bug-(Gnome|KDE|..) for other projects. My concern is that Ubuntu already has a policy like this (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I would really like ours to be compatible with theirs, so patches can freely be copied between Ubuntu and Debian. Having a different format sounds like a very bad idea. Have you tried contacting the
Re: RFC: DEP-3: Patch Tagging Guidelines
Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit : * `Bug-Vendor` or `Bug` (optional) -It contains one or more URLs (space separated) pointing to the related bugs -(possibly fixed by the patch). The `Bug` field is reserved -for the bug URL(s) in the upstream bug tracker. +It contains one URL pointing to the related bug (possibly fixed by the +patch). The `Bug` field is reserved for the bug URL in the upstream +bug tracker. Those fields can be used multiple times if several +bugs are concerned. It’s already better, but for more readability, would it be possible to have a registered list of bug tracking aliases? For example: Bug-Debian: #12345 Bug-Ubuntu: #2356 Bug-GNOME: #5671 Otherwise, I appreciate the proposed changes. They make it less of a problem if the information in the package is not up-to-date and follow our maintenance process closely. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
On Fri, 19 Jun 2009, Lucas Nussbaum wrote: distribution, so I don't mind if not all packages are converted, after it's up to you to see if new lintian warnings annoy you enough or not to live with it. :) See my comment above about this. It should be added to the introduction of the DEP. Ok. I added: --- a/web/deps/dep3.mdwn +++ b/web/deps/dep3.mdwn @@ -33,6 +33,17 @@ first step is to include those information in the patches when th available so that tools like the [Patch Tracking System](http://patch-tracking.debian.net) can display them. +Scope and application +- + +The usage of this format is highly recommended but as long as it's not +endorsed by the Debian policy, it will not be required. It is however +expected that tools like lintian will be modified to recommend adding +those information in patches. As the technical impact on package is null, +there's no need to organize a time-limited transition. All maintainers +can start using this format while doing their regular uploads, there's no +need to upload new revisions of packages just for adding those +information. Structure - Debian: could be considered a shorthand alias for Bug-Debian maybe? I guess that could also address the above issue that i mentioned. See my answer to Lucas. Well, you didn't answer my point: We could have Debian: for the Debian bug, and Bug-(Gnome|KDE|..) for other projects. My concern is that Ubuntu already has a policy like this (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I would really like ours to be compatible with theirs, so patches can freely be copied between Ubuntu and Debian. Having a different format sounds like a very bad idea. Have you tried contacting the people involved in the Ubuntu policy? It might be possible to change it. I did not contact them yet. I expect that they will follow the outcome of this DEP otherwise they would have to patch lintian to support the differing field and it seems counter-productive. I am perfectly aware that this DEP is not 100% compatible to their format and this field is only one difference, there are others (the way we handle the DebianSpecific tagging). So I'm not sure that we have to do something special here. Anyway, I'll send them a mail so that they can state their opinion here. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
2009/6/19 Josselin Mouette j...@debian.org: It’s already better, but for more readability, would it be possible to have a registered list of bug tracking aliases? For example: Bug-Debian: #12345 Bug-Ubuntu: #2356 Bug-GNOME: #5671 Personally I'd prefer URLs (for all bugs, including Debian ones) for the simple reason that no additional information is needed to access the bugs. -- 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: DEP-3: Patch Tagging Guidelines
On Fri, 19 Jun 2009, Josselin Mouette wrote: Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit : * `Bug-Vendor` or `Bug` (optional) -It contains one or more URLs (space separated) pointing to the related bugs -(possibly fixed by the patch). The `Bug` field is reserved -for the bug URL(s) in the upstream bug tracker. +It contains one URL pointing to the related bug (possibly fixed by the +patch). The `Bug` field is reserved for the bug URL in the upstream +bug tracker. Those fields can be used multiple times if several +bugs are concerned. It’s already better, but for more readability, would it be possible to have a registered list of bug tracking aliases? For example: Bug-Debian: #12345 Bug-Ubuntu: #2356 Bug-GNOME: #5671 It should be possible. I see one problem here though. Bug-Gnome is really Bug because it's the upstream bug. While we can have an URL mapping for each vendor, it's not possible for the non-qualified entry used for the upstream case. Otherwise, I appreciate the proposed changes. They make it less of a problem if the information in the package is not up-to-date and follow our maintenance process closely. Thanks for the feedback. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 19/06/09 at 10:49 +0200, Raphael Hertzog wrote: My concern is that Ubuntu already has a policy like this (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I would really like ours to be compatible with theirs, so patches can freely be copied between Ubuntu and Debian. Having a different format sounds like a very bad idea. Have you tried contacting the people involved in the Ubuntu policy? It might be possible to change it. I did not contact them yet. I expect that they will follow the outcome of this DEP otherwise they would have to patch lintian to support the differing field and it seems counter-productive. That sounds like a pretty bad way to force them to make changes to an existing policy. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit : I did not contact them yet. I expect that they will follow the outcome of this DEP otherwise they would have to patch lintian to support the differing field and it seems counter-productive. That sounds like a pretty bad way to force them to make changes to an existing policy. It is just normal that such things happen given how the development process of Ubuntu works. When upstream implements something for which I have already a patch but in a different way, I’m not going to complain to them if I have not bothered earlier to forward my patch and discuss it with them so that it is integrated. The same reasoning applies here. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit : It’s already better, but for more readability, would it be possible to have a registered list of bug tracking aliases? For example: Bug-Debian: #12345 Bug-Ubuntu: #2356 Bug-GNOME: #5671 It should be possible. I see one problem here though. Bug-Gnome is really Bug because it's the upstream bug. While we can have an URL mapping for each vendor, it's not possible for the non-qualified entry used for the upstream case. I don’t think one of these entries should be qualified as “the” canonical upstream bug. When I forward a bug to epiphany, if I add a Bug: pointing to GNOME, later it can be forwarded by them to Mozilla/Webkit because the patch turns out to be a workaround for a bug in the engine. That would make suddenly the Bug field turn into a Bug-GNOME, and a new Bug field would be introduced, pointing to Mozilla/Webkit? I think it’s bad design to rely on too much expectations based on a particular case. The only thing that’s generic is that patches are related to bugs that can lie in various trackers. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
On Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog wrote: On Mon, 15 Jun 2009, Mark Brown wrote: On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: * `Signed-off-by` (optional) For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. I started first with Reviewed-by and then thought that it was stupid to not reuse the name that is already vastly used for a similar purpose. What do other people think? I'm fine with both names. My point here is that Signed-off-by is widely used for a *different* purpose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Hi Raphaël, On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. Having this kind of information in patches if useful. Those of us that maintain their quilt patches on patch-queue branches in git have most of the information already autogenerated by git-format-patch: $ cat 0004-fix-Debian-specific-path-to-hvm-loader.patch From: Guido Guenther a...@sigxcpu.org Date: Thu, 26 Feb 2009 14:29:58 +0100 Subject: [PATCH] fix Debian specific path to hvm loader Closes: #517059 --- src/xen_internal.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/xen_internal.c b/src/xen_internal.c ... So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin (Author) are already there, some of them already being used by other tools (git-dch). Wouldn't it make sense to choose (or at least allow for) a format that's compatbile with what git-format-patch generates? 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: DEP-3: Patch Tagging Guidelines
On Fri, 19 Jun 2009, Josselin Mouette wrote: It should be possible. I see one problem here though. Bug-Gnome is really Bug because it's the upstream bug. While we can have an URL mapping for each vendor, it's not possible for the non-qualified entry used for the upstream case. I don’t think one of these entries should be qualified as “the” canonical upstream bug. When I forward a bug to epiphany, if I add a Bug: pointing to GNOME, later it can be forwarded by them to Mozilla/Webkit because the patch turns out to be a workaround for a bug in the engine. That would make suddenly the Bug field turn into a Bug-GNOME, and a new Bug field would be introduced, pointing to Mozilla/Webkit? No, the patch is against epiphany even if it's a work-around for a mozilla/webkit bug (so it's always Bug). You could add a Bug-Mozilla: if you wanted but I don't see that as a necessity. The (epiphany|upstream) bug entry will already contain that information in most cases. I think it’s bad design to rely on too much expectations based on a particular case. The only thing that’s generic is that patches are related to bugs that can lie in various trackers. And a patch applies to a particular software. That software is what we consider as upstream compared to us. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 2009-06-19, Raphael Hertzog hert...@debian.org wrote: +Scope and application +- + +The usage of this format is highly recommended but as long as it's not +endorsed by the Debian policy, it will not be required. It is however And there is no plan to make it required in the future +expected that tools like lintian will be modified to recommend adding +those information in patches. As the technical impact on package is null, Please do not decrease the usability of lintian even further. In linitan speak, this should be a pedantic tag at most. Structure - I think it should be much more focused on Please add the following information to your patches: What it does, where you got it from, who wrote it and so on. and a paragraph about This is a way of organizing this information to present it in a nice formatted way for interested upstreams, other distributions and other consumers of patches If people choose to use this new format, tools should choke/warn if there was more foo: bar fields in the patch than in the specification. I will have patches with headers like qt-bugs@ issue: 123 applied: yes http://patch-tracking.debian.net/patch/series/view/qt4-x11/4.5.1-2/0225-invalidate-tabbar-geometry-on-refresh.patch for example and more such custom headers. And that must be fully valid. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 19/06/09 at 11:14 +0200, Josselin Mouette wrote: Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit : I did not contact them yet. I expect that they will follow the outcome of this DEP otherwise they would have to patch lintian to support the differing field and it seems counter-productive. That sounds like a pretty bad way to force them to make changes to an existing policy. It is just normal that such things happen given how the development process of Ubuntu works. When upstream implements something for which I have already a patch but in a different way, I’m not going to complain to them if I have not bothered earlier to forward my patch and discuss it with them so that it is integrated. The same reasoning applies here. I agree that it was a bad thing that Ubuntu developers developed that policy without discussing it with Debian, or even mentionning it to Debian. That's not a reason for us to behave equally badly. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: RFC: DEP-3: Patch Tagging Guidelines
On Wed, 17 Jun 2009 12:40:01 +0200 Raphael Hertzog hert...@debian.org wrote: For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. I started first with Reviewed-by and then thought that it was stupid to not reuse the name that is already vastly used for a similar purpose. What do other people think? I'm fine with both names. Vastly used in the git world, not as vastly used outside of it. Reviewed-by conveys the same information and is more easily understandable IMHO. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. pgpDQfuEuDkPi.pgp Description: PGP signature
Re: RFC: DEP-3: Patch Tagging Guidelines
Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit : It’s already better, but for more readability, would it be possible to have a registered list of bug tracking aliases? For example: Bug-Debian: #12345 Bug-Ubuntu: #2356 Bug-GNOME: #5671 It should be possible. I see one problem here though. Bug-Gnome is really Bug because it's the upstream bug. While we can have an URL mapping for each vendor, it's not possible for the non-qualified entry used for the upstream case. BTW to solve this, it is only needed to accept a little change in the accepted syntax: Bug-Ubuntu: #12345 Bug: GNOME #5671 -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit : +The usage of this format is highly recommended but as long as it's not +endorsed by the Debian policy, it will not be required. It is however And there is no plan to make it required in the future What is the point of introducing this spec if it is not made mandatory at some point in the future? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
Le Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog a écrit : On Tue, 16 Jun 2009, Charles Plessy wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. I have no opposition against an optional License field. Can you try to word a description for it? On the other side, I'm also not convinced it's really useful... if a patch author wants some specific licence different from upstream's license, he should make that explicit in the patch itself when he adds his own copyright notice. Hi Raphaël, if it is obvious for everybody that any patch for a given file is implicitely licensed under the same license as the file, then the License: field is not necessary. This of course makes people releasing some code under non-free terms when they prepare a patch for non-free packages for instance, which in case of a significant contribution could potentially be an obstacle to a relicensing to a free license if the patch is accepted upstream and author can not be reached later. But this is a corner case that can be resolved with a comment in the patch or by other means. At your option, here is nevertheless a description. License (optional): indicates the license under which the patch is released. Note that trivial works are anyway not copyrightable, and that in the vast majority of the cases it is expected that the patch is released under the same terms as the files it applies to. Nevertheless, you can use this field to clarify ambiguous situations, for instance when the license of the packaging work is not the same as the packaged program, or when you would like to give permission to the upstream copyright holder(s) to relicense the patched work later (in case the current license is problematic). PS: I also prefer Reviewed-by to Signed-off. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Josselin Mouette wrote: Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit : +The usage of this format is highly recommended but as long as it's not +endorsed by the Debian policy, it will not be required. It is however And there is no plan to make it required in the future What is the point of introducing this spec if it is not made mandatory at some point in the future? compare internet: - it work fine - it doesn't mandate any RFC - it would be a mess not having RFC. Personally I think we are too far to mandate DEP-3 (and BTW the subject has guideline, not requirements): - we need to use the new source format - we need to have experiences with new dpkg-source and new tagging, and to found problem - and probably new discussion about real problems. so, IMHO we need a complete guidelines and start to use it widely. It should not be complete or 100% precise (so not yet the right time for bike-shading). Then from time to time we could include some mature items in the policy and discuss improvements. Anyway I think we will need a guideline in parallel to the policy: the guideline could explain better the problem and the solutions, future directions, recommendations etc. then the policy. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit : What is the point of introducing this spec if it is not made mandatory at some point in the future? so, IMHO we need a complete guidelines and start to use it widely. It should not be complete or 100% precise (so not yet the right time for bike-shading). Then from time to time we could include some mature items in the policy and discuss improvements. “Some point in the future” does not have to be tomorrow. But if, right from the start, the guidelines are designed so that they can’t be made mandatory later, they must be broken somehow. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
Josselin Mouette wrote: Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit : What is the point of introducing this spec if it is not made mandatory at some point in the future? so, IMHO we need a complete guidelines and start to use it widely. It should not be complete or 100% precise (so not yet the right time for bike-shading). Then from time to time we could include some mature items in the policy and discuss improvements. “Some point in the future” does not have to be tomorrow. But if, right from the start, the guidelines are designed so that they can’t be made mandatory later, they must be broken somehow. I'm not so sure, but it is not so important that we doesn't agree on this point. but on DEP-3? No! I think DEP-3 development should be stopped soon, and we should apply it. Any thing that it will be included in the policy, it will not be DEP-3, but based on DEP-3. A step toward a standardization, but not a part of standard itself. In this case I think we should use DEP-3 without discussion every details: we need a larger user base, then we will discuss details for standardization, but not now. I think this was the original misunderstanding. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Fri, 19 Jun 2009, Sune Vuorela wrote: On 2009-06-19, Raphael Hertzog hert...@debian.org wrote: +Scope and application +- + +The usage of this format is highly recommended but as long as it's not +endorsed by the Debian policy, it will not be required. It is however And there is no plan to make it required in the future I won't put this in here. I have no reason to stop people from making it mandatory in the future. You will have to re-raise your concerns when the debian-policy discussion happens (if it happens). +expected that tools like lintian will be modified to recommend adding +those information in patches. As the technical impact on package is null, Please do not decrease the usability of lintian even further. In linitan speak, this should be a pedantic tag at most. I will leave that up to lintian maintainers. If people choose to use this new format, tools should choke/warn if there was more foo: bar fields in the patch than in the specification. I will have patches with headers like qt-bugs@ issue: 123 applied: yes http://patch-tracking.debian.net/patch/series/view/qt4-x11/4.5.1-2/0225-invalidate-tabbar-geometry-on-refresh.patch for example and more such custom headers. And that must be fully valid. Leave a blank line after the official headers and you'll be able to put whatever you want. Otherwise we can also decide to have X- for prefix for custom headers if you prefer. On Fri, 19 Jun 2009, Giacomo Catenazzi wrote: Personally I think we are too far to mandate DEP-3 (and BTW the subject has guideline, not requirements): - we need to use the new source format - we need to have experiences with new dpkg-source and new tagging, and to found problem - and probably new discussion about real problems. Well, no, we don't need any of that. We already have experience with handling patches... and we are able to define a good format now that should not need to evolve much in the future. Then from time to time we could include some mature items in the policy and discuss improvements. While it's possible that some gradual improvements happen over time, the day where policy officialize this, I expect it will be mostly cut paste of what we have since policy should document current practice when something is widely used already. On Fri, 19 Jun 2009, Giacomo A. Catenazzi wrote: In this case I think we should use DEP-3 without discussion every details: we need a larger user base, then we will discuss details for standardization, but not now. I prefer we take the time to think it thoroughly so that we don't have to come back to it later. It's easier to standardize something that works and has seen no need for substantial changes since X months rather than a recommendation that changes every other month because it has not been well fleshed out. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: On Fri, 19 Jun 2009, Giacomo A. Catenazzi wrote: In this case I think we should use DEP-3 without discussion every details: we need a larger user base, then we will discuss details for standardization, but not now. I prefer we take the time to think it thoroughly so that we don't have to come back to it later. It's easier to standardize something that works and has seen no need for substantial changes since X months rather than a recommendation that changes every other month because it has not been well fleshed out. Yes, but: - don't over-engineering - don't wait to much on details (we don't want a debian/control discussion over one year) and: - most standard are done by/after usage - we don't know the main problems and errors of normal DDs and the integration workflow with various vcs tools. I really think that in one year we need to discuss again about some items (License field was need? Bug is used correctly? Signed-Off is needed? Forgot something? Team tags? Are there a lot of template text). The main idea and structure is already given by DEP-3, and there is no critical information, so I think it will not confuse user an update, but such updates will clarify some aspect we now don't see. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog hert...@debian.org writes: Merging all those ideas, I suggest we drop Status/Commit/Patch and use the following format: Origin: upstream|backport|vendor|other : url-or-commit I'd still suggest having the extra information optional in the case of anything but “other”: Origin: upstream [ : url-or-commit ] Origin: backport [ : url-or-commit ] Origin: vendor [ : url-or-commit ] Origin: other: url-or-commit In other words, a keyword is required, and extra information is optional except for “other”. Forwarded: yes|no|not-needed|url-or-text Again, I'll warn against specifying “one of these keywords, or whatever you like” since that begs for collisions in future when trying to introduce new keywords. Instead, I would specify ‘Forwarded’ similar to the above, with: Forwarded: yes [ : url-or-text ] Forwarded: no [ : url-or-text ] Forwarded: not-needed: url-or-text -- \“When you go in for a job interview, I think a good thing to | `\ ask is if they ever press charges.” —Jack Handey | _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: DEP-3: Patch Tagging Guidelines
Joerg Jaspert wrote: On 11782 March 1977, Raphael Hertzog wrote: This is a proposal to formalize a set of meta-information to be embedded in patches applied to Debian packages. Most patch systems allow for a free-from description preceeding the content of the patch and the plan is to make use of that space to embed some structured content. It does sound a *little* overengineered for no good reason. (IMO). I usually tend to like and support some changes even if they are a big change, but in this case I agree with you Joerg. I mean, often the patch name already says enough about it, at times patches are just trivial (a typo fix doesn't need four or five lines to be described), at times they are forwarded as soon as the new package is uploaded, at times they are $VCS commits from upstream. And mandating or even recommending to add all that documentation is useless in those, and probably more, cases. The only part I consider worth to keep is the one where the status regarding forwarding the patch to upstream is recorded. Something as simple as: Status: forwarded to f...@bar.com Status: forwarded to http://some.bts.foo.com/bar?id=moo Status: not forwarded Status: not forwarded, Debian-specific It's perfectly human and machine readable, and is pretty simple. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog hert...@debian.org writes: * `Origin` (required) This field should document the origin of the patch. It can have the following standard values: upstream (in the case of a patch cherry-picked from the upstream VCS), backport (in the case of an upstream patch that had to be modified to apply on the current version). Any other value is supposed to be free-form text describing the origin of the patch. This field specification makes it problematic to introduce additional standard values later, without potentially colliding with existing free-form text values already in use before the new value was introduced. Suggestion for improving this field specification: * `Origin` (required) This field should document the origin of the patch. It must be of the following forms:: keyword keyword : description The description is free-form text giving more information about the origin of the patch. The keyword is one of the following: * `upstream`, for a patch cherry-picked from the upstream VCS and applied directly. * `backport`, for an upstream patch modified to apply to the current version of the source. * `other`, for an origin not covered by any of the above keywords. Perhaps that could be made more concise, but I hope the intent is clear this way. -- \“The errors of great men are venerable because they are more | `\ fruitful than the truths of little men.” —Friedrich Nietzsche | _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: DEP-3: Patch Tagging Guidelines
On Mon, 15 Jun 2009, Lucas Nussbaum wrote: * `Bug-Vendor` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? The reason I wanted a common prefix is that we don't have an authoritative list of vendors and as such it would be best if the content of the field could be validated based on the common prefix. * `Status` (optional) Why optional? Because there are cases where its value is implicit. If we have Origin: upstream (or backport) then it's not needed. That said, it looks like several people would like to not have both field in the current form. I'll try to come up with a proposal to merge both in some meaningful way. If you have an idea, feel free to propose it. * `Signed-off-by` (optional) I don't think that this field is necessary. If people want to credit other people in their patches, they can do so in the Description:. It's not (only) about credit here, it's about knowing if the patch has been reviewed and by whom. I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. Re-read the description of Status, it already contains this: | The first line should consist of a single keyword among | lt;vendorgt;-specific (the patch must not be forwarded as it is | specific to a vendor, ex: branding patches), [...] | Supplementary lines can be used to explain in more details the status of | the patch. It should be used for example to explain why the patch has | been rejected, or why this change is only meaningful for the vendor. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, 16 Jun 2009, Felipe Sateler wrote: If the idea is to standarize metainformation, I would suggest standarizing filenaming scheme too. What I do in some packages is to name the patches as follows: 0xxx-name.patch - Grabbed from upstream VCS 1xxx-name.patch - Interesting for submission upstream 2xxx-name.patch - Debian-specific I don't want to go in that direction. I don't want to impose too many restrictions on the way patch are managed inside the package. That would simply create one more unnecessary obstacle to its widespread adoption. Many people use directories for that, other uses prefixes, other simply do not care as long as the information is available in the comment inside the patch. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 17/06/09 at 09:04 +0200, Raphael Hertzog wrote: On Mon, 15 Jun 2009, Lucas Nussbaum wrote: * `Bug-Vendor` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? The reason I wanted a common prefix is that we don't have an authoritative list of vendors and as such it would be best if the content of the field could be validated based on the common prefix. We could have Debian: for the Debian bug, and Bug-(Gnome|KDE|..) for other projects. I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. Re-read the description of Status, it already contains this: | The first line should consist of a single keyword among | lt;vendorgt;-specific (the patch must not be forwarded as it is | specific to a vendor, ex: branding patches), [...] | Supplementary lines can be used to explain in more details the status of | the patch. It should be used for example to explain why the patch has | been rejected, or why this change is only meaningful for the vendor. I think that this information is important enough not to be inside supplementary lines of an optional tag... -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Hello everybody, I'll try to do some new proposals based on your feedback. But first let me address the topic of the usefulness of the proposal. While there are currently no tools making use of this format, I can imagine many interesting usage for this information. It starts with the simple stats (how many debian specific patch do we use?) and goes on to providing a nice web interface where people can browse all patches: - check all non-forwarded patches and help forwarding them - let upstream developers browse all patches which are not backports - let other distributions check all patches which are not debian-specific In any case, it's a required step IMO if we want to increase the visibility of our patches and ensure they are better reviewed. As you have noted, the format is quite simple and you don't have to use everything it can offer at the start if you feel it would take too much time. Only Description and Origin are required. The requirement is not enforced but it's the minimum needed to make it DEP3-compliant. :) While a formal process is not needed to start using something like this in my own packages (and I already did), I believe it's important to have this discussion so that we have something broadly accepted to build upon. Otherwise I keep reinventing field names and it's more difficult to integrate it in the Debian ecosystem (lintian, dpkg-dev, etc.). I hope we can all agree that it can be useful, that we can make it lightweight enough so that it's not a big pain for maintainers and as such that's it's a step in the right direction. Now let's go back to the content of the proposal. On Mon, 15 Jun 2009, Sune Vuorela wrote: Wouldn't a better first goal be to have just a freeform text field ? With the current amount of comments in the patches of random packages I touch, just a oneliner would be a significatn improvement. AS long as not a major part of debian people comment their patches, the format really doesn't matter. I agree that one sentence is better than nothing, however I don't see why this would forbid other maintainers to use something more elaborated. Furthermore the format allows for simple things like: Description: Change the pid file path Origin: Debian So hopefully the format will not make maintainers run away because it's too complex. On Mon, 15 Jun 2009, Mark Brown wrote: On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: * `Signed-off-by` (optional) This field can be used to document the fact that the patch has been reviewed by one or more persons. It should list their names and emails in the standard format (similar to the example given for the `Origin` field), separated by commas if needed. For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. I started first with Reviewed-by and then thought that it was stupid to not reuse the name that is already vastly used for a similar purpose. What do other people think? I'm fine with both names. On Tue, 16 Jun 2009, Charles Plessy wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. I have no opposition against an optional License field. Can you try to word a description for it? On the other side, I'm also not convinced it's really useful... if a patch author wants some specific licence different from upstream's license, he should make that explicit in the patch itself when he adds his own copyright notice. for your effort to unifiy the format. Personally, I do not mind changing our local format for the DEP3 format as long as we have one release cycle to do it. Some of our packages have a very slow turnover. There's no forced switch planned... it has not technical impact on the distribution, so I don't mind if not all packages are converted, after it's up to you to see if new lintian warnings annoy you enough or not to live with it. :) Now I'll switch to the discussion about the Origin/Status/Patch fields. It seems that this set of fields is not as optimized as it could be. On Mon, 15 Jun 2009, Josselin Mouette wrote: Le lundi 15 juin 2009 à 18:12 +0200, Raphael Hertzog a écrit : * `Patch` (optional) Maintaining this information up-to-date can be troublesome. * `Status` (optional) Same here. At the moment a package is uploaded, it can be must-be-forwarded, then later it becomes forwarded and later on it can change again. Which means a lot of additional commits, and that the version in sid can be
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog hert...@debian.org wrote: Hello everybody, I'll try to do some new proposals based on your feedback. But first let me address the topic of the usefulness of the proposal. While there are currently no tools making use of this format, [...] In any case, it's a required step IMO if we want to increase the visibility of our patches and ensure they are better reviewed. I think that one important aspect of that format would be that it also says which content should be given. And having that content in more patches in Debian would be very useful even for non-tools (read: people). When adding a new patch, empty fields remind you to write *something* instead of just dropping the diff into debian/patches... Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 2009-06-16, Paul Wise p...@debian.org wrote: On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? There is several, and it just got changed to gplv3. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Hi Raphaël, On Mon, June 15, 2009 18:12, Raphael Hertzog wrote: please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. For me a key question that the proposal doesn't answer is what value this formalisation would add. Yes, indeed patches should be commented, but what is the problem with the current situation where we just put freeform text above the patch? That works fine for me. Every formalisation has a cost and I'm not sure here that it's offset by the (which?) benefits. Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote: On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote: On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information Putting the information in the changelog makes it much harder to find Yes, putting the information _only_ in the changelog make it much harder to find, but that is not what I did nor what I proposed. As you can see, my patch header is a copy of the changelog entry, so you don't even need to open the changelog file to get all relevant information. You might've wanted to make that more explicit in the message - saying just use[ing] the changelog entry gives a different impression. If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. That's the idea - make the data available for software. I'd also expect to see the standard headers encourage the recording of information that gets a standard header, it's certainly helped that in Linux. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 10:05:40AM +0100, Mark Brown wrote: On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote: If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. That's the idea - make the data available for software. Well, which software, which use case? You don't need a special format to display headers in the Debian patch tracking system. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Thijs Kinkhorst th...@debian.org writes: Hi Raphaël, On Mon, June 15, 2009 18:12, Raphael Hertzog wrote: please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. For me a key question that the proposal doesn't answer is what value this formalisation would add. Yes, indeed patches should be commented, but what is the problem with the current situation where we just put freeform text above the patch? That works fine for me. Every formalisation has a cost and I'm not sure here that it's offset by the (which?) benefits. Possible benefits (partly mentioned in the spec) - tools can be adapted/crafted to maintain these fields - streamline development practice to faciliate team communication - (web)tools can analyse and produce statistics I'm looking forward to see prototype implementations of tools that use patch files formatted this way. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 11:23:17AM +0200, Reinhard Tartler wrote: Thijs Kinkhorst th...@debian.org writes: above the patch? That works fine for me. Every formalisation has a cost and I'm not sure here that it's offset by the (which?) benefits. Possible benefits (partly mentioned in the spec) - tools can be adapted/crafted to maintain these fields - streamline development practice to faciliate team communication - (web)tools can analyse and produce statistics I'm looking forward to see prototype implementations of tools that use patch files formatted this way. I'd also add that having something like this often encourages people to record the information that's standardised by virtue of providing a blank to be filled in. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, June 16, 2009 11:23, Reinhard Tartler wrote: Thijs Kinkhorst th...@debian.org writes: Hi Raphaël, On Mon, June 15, 2009 18:12, Raphael Hertzog wrote: please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. For me a key question that the proposal doesn't answer is what value this formalisation would add. Yes, indeed patches should be commented, but what is the problem with the current situation where we just put freeform text above the patch? That works fine for me. Every formalisation has a cost and I'm not sure here that it's offset by the (which?) benefits. Possible benefits (partly mentioned in the spec) - tools can be adapted/crafted to maintain these fields - streamline development practice to faciliate team communication - (web)tools can analyse and produce statistics.. This is still quite abstract: streamline development practice to faciliate team communication, what does this mean? I haven't yet needed any tool to type the freeform text above our patches. Indeed, statistics can be made, but the real benefit in statistics is the conclusions that are drawn from them. Until now the advantages remain in vague terms. Can we make it more specific what the streamlining is or what use there would be of statistics on this metadata? Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Thijs Kinkhorst th...@debian.org writes: Possible benefits (partly mentioned in the spec) - tools can be adapted/crafted to maintain these fields - streamline development practice to faciliate team communication - (web)tools can analyse and produce statistics.. This is still quite abstract: streamline development practice to faciliate team communication, what does this mean? I haven't yet needed any tool to type the freeform text above our patches. Indeed, statistics can be made, but the real benefit in statistics is the conclusions that are drawn from them. Until now the advantages remain in vague terms. Can we make it more specific what the streamlining is or what use there would be of statistics on this metadata? What I meant is that IME, patch files are hardly documented at all, and even if they are, not all required information is available. Most of the fields are not necessary if you work alone on a package, right. But if you join a team, see a team maintained package with patches in it, you immediately start asking yourself about the patch purpose, status in debian and upstream and so on. Having the format here standardised streamlines the workflow in the sense that: - all required information is availabe - no need to ask the last developer on the package about patch status, upstream submission, etc - encourages finally documenting the patches. In some way, yes, properly maintaining these fields does require some work. If you're working alone on the package, I agree that maintaining that information does not bring a direct benefit to you. Most benefits in this DEP are for the team (and in some ways debian) maintaining the package. What we can and should be discussed is what fields are absolutely required to maintain. Most of the fields are optional for good reason, but given nevertheless in the spec to define semantics on them, which is good IMO. The set of required fields seems reasonable to me. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Carsten Hey wrote: On Tue, Jun 16, 2009 at 10:05:40AM +0100, Mark Brown wrote: On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote: If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. That's the idea - make the data available for software. Well, which software, which use case? You don't need a special format to display headers in the Debian patch tracking system. As mentioned in the original proposal, one could make a (tentative) list of all patches that have not been submitted upstream but are not debian- specific. Not mentioned in the original proposal: for QA work, one could produce a (again, tentative) list of packages which contain (maybe lots of) patches fixing bugs in debian but are not forwarded/incorporated upstream, which may be an indicator of dead upstreams. If someone starts collecting patch history about the packages, one could make also a list of packages that have non-debian specific patches that have been applied across several upstream versions, perhaps indicating lack of manpower/will/spiritual strength to coordinate/endure/work with upstream. Of course, all this information may or may not be interesting to anybody. -- 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: DEP-3: Patch Tagging Guidelines
hi, (yay for group reply) On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: * `Description` (required) This obligatory field contains at least a short description on the first line. Supplementary lines can be used to provide a longer explanation of the patch. given that the patches which currently have useful information do so via freeform comments, i think that it would be very useful to explicitly include this in the format. i.e. anything that doesn't conform to the standard header/value format could be taken as the description. * `Origin` (required) This field should document the origin of the patch. It can have the this guy feels a bit over-engineered/over-generalized to me. * `Bug-Vendor` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. if Bug can refer to more than one bug than perhaps Bugs would be better, or alternatively you could allow the field to have duplicate instances. Also, from reading this i'm assuming that debian bugs would be identified by Bug(s)-Debian? that seems a bit unwieldly, esp given that there will likely be more references to debian bugs than upstream/cross-stream bugs. Maybe we should also add a special shorthand for Closes: #nnn or similar? My personal preference is that Debian gets Bug and there's a seperate Bug(s)-Upstream field, but maybe there are also arguments to the contrary? also, for the more commonly referenced BTS's (BTS and LP) it'd be nice for the spec to allow us to refer to them in shorthand (# or LP#). * `Status` (optional) honestly i don't see this as something that people would keep up to date. i think that it's something that could rather be implicitly determined with smart use of existing information (assuming that there are debian and upstream bugs to reference, and possibly some bts-link glue). and since it's by nature rather volatile, i think it otherwise invites extra and un-needed work for the maintainer. * Has the patch been forwarded upstream? why not have a field for that instead? for example: * `Forwarded` (optional) Has the bug been forwarded to upstream? Any value other than No or no will be taken as a postive value. If the value is a URL, then it is inferred that it points to an online discussion related to forwarding the patch to upstream. The value is also implicitly considered positive if there are upstream bug references elsewhere in the headers. this would allow for: Forwarded: Yes -or- Forwarded: http://lists.upstream.org/msg12345.html -or- Bug: http://bugs.upstream.org/bug12345.html (which implicitly states that it's forwarded) i guess there's still the corner case where we found an upstream bug and fixed it locally but did not send the patch back but referenced the upstream bug in the patch anyway, but that's just... mean (and bts-link or a simple human observation would show that the bug hadn't been forwarded). On Mon, Jun 15, 2009 at 06:27:45PM +0200, Lucas Nussbaum wrote: (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? Debian: could be considered a shorthand alias for Bug-Debian maybe? I guess that could also address the above issue that i mentioned. I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. i think something like this would be useful as well. i'll throw a suggestion out there: * `Debian-Specific` (optional) Is this patch a debian-specific patch that is not intended to be shared with upstream? For example, changes to specify Debian-specific application paths, configuration file locations, etc. On Mon, Jun 15, 2009 at 07:04:59PM +0200, Josselin Mouette wrote: * `Patch` (optional) URL pointing to the patch. It can be in a VCS web interface, a BTS attachment, etc. If the patch is available in the upstream VCS or BTS, those URLs take precedence. Maintaining this information up-to-date can be troublesome. i don't think it's incredibly interesting either, apart from where did this come from, which kinda blurs together with Origin at least in my mind. I think if Origin were made a little less general it could also assume the purpose of this field. On Mon, Jun 15, 2009 at 09:37:43PM +0200, Joerg Jaspert wrote: It does sound a *little* overengineered for no good reason. (IMO). yeah, i also think it could be simpler without failing the original intention. also, the use of optional vs. required seems a bit presumptuous given that there's nothing requiring anything at all in the patch headers atm. How about
Re: RFC: DEP-3: Patch Tagging Guidelines
On 16/06/09 at 17:18 +0200, sean finney wrote: On Mon, Jun 15, 2009 at 06:27:45PM +0200, Lucas Nussbaum wrote: (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? Debian: could be considered a shorthand alias for Bug-Debian maybe? I guess that could also address the above issue that i mentioned. Let's not add aliases for the tag names now, please :-) I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. i think something like this would be useful as well. i'll throw a suggestion out there: * `Debian-Specific` (optional) Is this patch a debian-specific patch that is not intended to be shared with upstream? For example, changes to specify Debian-specific application paths, configuration file locations, etc. The rationale for using DebianSpecific (instead of Debian-Specific) is that Ubuntu uses UbuntuSpecific, not Ubuntu-Specific. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 05:44:55PM +0200, Lucas Nussbaum wrote: * `Debian-Specific` (optional) Is this patch a debian-specific patch that is not intended to be shared with upstream? For example, changes to specify Debian-specific application paths, configuration file locations, etc. The rationale for using DebianSpecific (instead of Debian-Specific) is that Ubuntu uses UbuntuSpecific, not Ubuntu-Specific. sure, i don't have any attachment to either, i was just blurting out some proposed text :) sean signature.asc Description: Digital signature
RFC: DEP-3: Patch Tagging Guidelines
Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. If (and once) we have consensus that it is good idea to standardize those information, we can take supplementary steps to ensure they are not forgotten and correctly filled: - lintian can advise using this format in quilt-patch-missing-description or dpatch-missing-description, it can also check for correctness when packages are trying to use of this format - in format 3.0 (quilt) dpkg-source would create initial headers respecting this format automatically based on the changelog when it creates a new patch - fix some tools to correctly preserve those information (apparently cdbs-edit-patch is not wise enough to do this by default) - the developers-reference could be updated to recommend usage of this format The latest version of the DEP is on the web: http://dep.debian.net/deps/dep3/ Text version follows: Title: Patch Tagging Guidelines DEP: 3 State: DRAFT Date: 2009-06-12 Drivers: Raphael Hertzog hert...@debian.org URL: http://dep.debian.net/deps/dep3 Abstract: Meta-information embedded in patches applied to Debian packages Introduction This is a proposal to formalize a set of meta-information to be embedded in patches applied to Debian packages. Most patch systems allow for a free-from description preceeding the content of the patch and the plan is to make use of that space to embed some structured content. Motivation -- In order to ensure high-quality in the distribution, it's important to facilitate the review of patches that are applied to Debian packages. To achieve this task we must be able to browse the patches and discover some information about them (their origin/author, if they have been forwarded upstream, if they are meant to be debian specific or not, etc.). Thus the first step is to include those information in the patches when they are available so that tools like the [Patch Tracking System](http://patch-tracking.debian.net) can display them. Structure - 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). For patch-systems like dpatch that require the patch to be a standalone script, the shebang line is ignored and it is possible to put those fields in comments. The line should then follow the format `# field`. For multi-line fields, the subsequent lines should start with `#`nbsp;nbsp; (dash followed by two spaces) so that they start with a space once `#` (dash followed by a space) has been stripped from the beginning. The set of fields ends on the first empty line. Free-form comments can follow and be used for any other information that does not fit in the structured content. Standard fields --- In the following section, `Vendor` can be Debian or the name of any other distribution that tracks the same problem/patch. * `Description` (required) This obligatory field contains at least a short description on the first line. Supplementary lines can be used to provide a longer explanation of the patch. * `Origin` (required) This field should document the origin of the patch. It can have the following standard values: upstream (in the case of a patch cherry-picked from the upstream VCS), backport (in the case of an upstream patch that had to be modified to apply on the current version). Any other value is supposed to be free-form text describing the origin of the patch. It should typically be the name and email of the patch author (ex: `John Bear f...@bar.net`) or the project/company that she worked for when she authored the patch. * `Bug-Vendor` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. * `Patch` (optional) URL pointing to the patch. It can be in a VCS web interface, a BTS attachment, etc. If the patch is available in the upstream VCS or BTS, those URLs take precedence. * `Commit` (optional) One or more commit identifiers. This should only be used when the `Patch` field can't be used because the upstream project has no VCS web interface or similar restrictions. * `Status` (optional) This field is a textual explanation of its status concerning its inclusion in the upstream project. The first line should consist of a single keyword among lt;vendorgt;-specific (the patch must not be forwarded as it is specific to a vendor, ex: branding patches), must-be-forwarded (nobody has taken the time to forward the patch yet),
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: * `Signed-off-by` (optional) This field can be used to document the fact that the patch has been reviewed by one or more persons. It should list their names and emails in the standard format (similar to the example given for the `Origin` field), separated by commas if needed. For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 15/06/09 at 18:12 +0200, Raphael Hertzog wrote: Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. Thanks a lot for starting the discussion on this. I think that standardizing on this would really help Debian and the free software community as a whole. * `Bug-Vendor` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? * `Status` (optional) Why optional? * `Signed-off-by` (optional) I don't think that this field is necessary. If people want to credit other people in their patches, they can do so in the Description:. I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. Thanks again, -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Le lundi 15 juin 2009 à 18:12 +0200, Raphael Hertzog a écrit : * `Patch` (optional) URL pointing to the patch. It can be in a VCS web interface, a BTS attachment, etc. If the patch is available in the upstream VCS or BTS, those URLs take precedence. Maintaining this information up-to-date can be troublesome. * `Status` (optional) This field is a textual explanation of its status concerning its inclusion in the upstream project. The first line should consist of a single keyword among lt;vendorgt;-specific (the patch must not be forwarded as it is specific to a vendor, ex: branding patches), must-be-forwarded (nobody has taken the time to forward the patch yet), forwarded (the patch has been forwarded, the Bug or Patch fields should contain the corresponding URLs) or rejected (the patch has been submitted but it has been rejected upstream). Supplementary lines can be used to explain in more details the status of the patch. It should be used for example to explain why the patch has been rejected, or why this change is only meaningful for the vendor. Same here. At the moment a package is uploaded, it can be must-be-forwarded, then later it becomes forwarded and later on it can change again. Which means a lot of additional commits, and that the version in sid can be easily outdated. It’s not that we can’t live with these issues, but we need to be aware of that. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
On 11782 March 1977, Raphael Hertzog wrote: This is a proposal to formalize a set of meta-information to be embedded in patches applied to Debian packages. Most patch systems allow for a free-from description preceeding the content of the patch and the plan is to make use of that space to embed some structured content. It does sound a *little* overengineered for no good reason. (IMO). How about starting to do that for your own packages and see how it works out. If it turns out to be great people will join and it will spread and at some point be something we could even enforce. Would also give this a little practice test to see if what you want from people is worth the work/trouble dealing with it. -- bye, Joerg What would you do if you wanted to retire from the project? This is far easier than to get in! ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, 2009-06-15 at 21:37 +0200, Joerg Jaspert wrote: On 11782 March 1977, Raphael Hertzog wrote: This is a proposal to formalize a set of meta-information to be embedded in patches applied to Debian packages. Most patch systems allow for a free-from description preceeding the content of the patch and the plan is to make use of that space to embed some structured content. It does sound a *little* overengineered for no good reason. (IMO). How about starting to do that for your own packages and see how it works out. If it turns out to be great people will join and it will spread and at some point be something we could even enforce. Would also give this a little practice test to see if what you want from people is worth the work/trouble dealing with it. We have been using something very similar to this in parts of Ubuntu for a while now (the wiki page on it is referenced in the DEP). I for one find it to be very useful and wish that it was more widespread. Yes, there can be a few fields for each patch, but you generally have the relevant links to hand when you are adding a patch anyway. There is growing use of the tags within Ubuntu, so there are obviously others that agree that it is useful. Whether Debian Developers wish to use it is obviously up to them, but I would think that this is one case where standardisation is very useful, even if it is the cart leading the horse to some extent. I need to re-read the DEP; I may have some suggestions about the content, but I agree whole-heartedly with the intent. I will also talk to people from other distributions about adopting the same fields. Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information like the author of the patch or a note like this is Debian specific, don't merge can also be included in a changelog file if this is relevant, as I did in the following example: debian/changelog: pal (0.4.3-2) unstable; urgency=low * debian/watch: use QA redirector. * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) -- Carsten Hey c@web.de Sat, 06 Sep 2008 07:13:08 +0200 debian/patches/50_debian_fix_example_path_in_manpage.patch: pal (0.4.3-2) * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) --- pal.orig/pal.1.template ... If you get the relevant information from git or any other source this is in my opinion also ok, as long as the header format is easy to parse for humans. Standardizing the format would be a must if this information should be parsed by computers, do you have any plans in this direction? I think there should be a consent _which_ information should be included in patch headers, but unless they must be parsed by machines a standard which defines _how_ these information should be presented just adds unnecessary work for the maintainers. For a definition which information should be in a header your proposal could act as a very good basis, but there should IMHO some defaults which fit in most cases, e.g. when no author is mentioned the current Debian maintainer is the author and the patch is assumed to be Debian originated unless noted otherwise. - in format 3.0 (quilt) dpkg-source would create initial headers respecting this format automatically based on the changelog when it creates a new patch Not everyone lets dpkg create new patches. Different maintainers, different workflows ... Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information Putting the information in the changelog makes it much harder to find when looking at a package source than if it's right there in the patch file - you need to look the patch up in the changelog and if the patch is revised or otherwise changes state over time you need to figure out what the current state is somehow. It's a similar idea to saying that code should be adequately commented - the revision control history should say what's going on too but it shouldn't be essential to reading the code. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 2009-06-15, Raphael Hertzog hert...@debian.org wrote: Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed Wouldn't a better first goal be to have just a freeform text field ? With the current amount of comments in the patches of random packages I touch, just a oneliner would be a significatn improvement. AS long as not a major part of debian people comment their patches, the format really doesn't matter. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote: On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information Putting the information in the changelog makes it much harder to find Yes, putting the information _only_ in the changelog make it much harder to find, but that is not what I did nor what I proposed. As you can see, my patch header is a copy of the changelog entry, so you don't even need to open the changelog file to get all relevant information. I proposed a free text format which should include specified information, whether this is a git like header, a copy of the changelog entry or anything else does not matter as long as it is readable and understandable. If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Le Mon, Jun 15, i2009 at 06:12:49PM +0200, Raphael Hertzog a écrit : Title: Patch Tagging Guidelines DEP: 3 State: DRAFT Date: 2009-06-12 Drivers: Raphael Hertzog hert...@debian.org URL: http://dep.debian.net/deps/dep3 Abstract: Meta-information embedded in patches applied to Debian packages * `Description` (required) * `Origin` (required) * `Bug-Vendor` or `Bug` (optional) * `Patch` (optional) * `Commit` (optional) * `Status` (optional) * `Signed-off-by` (optional) Bonjour Raphaël, in the Debian Med packaging team, we use a similar approach for many of our packages: * Author (optional) * Description (optional) * Forwarded (optional) * License (optional) In ‘Description’ we put everything that would be in Patch, Commit and Bug. ‘Forwarded’ sometimes uses a short/long semantic à la debian/control, where the first line contains either ‘no’, an URL or an email address, and the following lines an optional long comment explaining for instance why the patch has not been forwarded. The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. I guess that other teams and individual developers use other variants. Thanks for your effort to unifiy the format. Personally, I do not mind changing our local format for the DEP3 format as long as we have one release cycle to do it. Some of our packages have a very slow turnover. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. If the idea is to standarize metainformation, I would suggest standarizing filenaming scheme too. What I do in some packages is to name the patches as follows: 0xxx-name.patch - Grabbed from upstream VCS 1xxx-name.patch - Interesting for submission upstream 2xxx-name.patch - Debian-specific The Status field is then no longer needed, since patches in 1xxx should be moved into 0xxx when accepted upstream, or into 2xxx if rejected for non- cosmetic reasons (ie, the purpose of the patch is not accepted, not just the current form). This has the added benefit that patches submitted upstream have a greater chance of applying cleanly against the current HEAD of development. The Origin field becomes optional too. snip * `Status` (optional) This field is a textual explanation of its status concerning its inclusion in the upstream project. The first line should consist of a single keyword among lt;vendorgt;-specific (the patch must not be forwarded as it is specific to a vendor, ex: branding patches), must-be-forwarded (nobody has taken the time to forward the patch yet), forwarded (the patch has been forwarded, the Bug or Patch fields should contain the corresponding URLs) or rejected (the patch has been submitted but it has been rejected upstream). Supplementary lines can be used to explain in more details the status of the patch. It should be used for example to explain why the patch has been rejected, or why this change is only meaningful for the vendor. This field misses a value for patches picked from upstream VCS. snip Interpretation -- In the analysis of the meta-information, a certain number of related facts can be deduced from the absence, presence, or combinations of fields and their values. * Has the patch been forwarded upstream? If there is a `Status` field, its value answers the question. If there's an `Origin` field and it contains upstream or backport, the patch comes from upstream and it doesn't need to be forwarded. The same is true if there's a `Commit` field. In other cases, if there is a `Bug` field, then the patch has most likely been referenced in the bug and upstream should know about it. Any package maintainer should ensure that the existence of the patch has been documented in the upstream bug log when he adds the patches' meta-information. I think answering a simple question (and one of the most likely to be asked about a patch) should be done by a simple rule. The Status field should be sufficient for this. Introduce a picked-from-upstream value for the Status field and then we are done. -- 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: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? -- 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
