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