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 <email@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/
Reply to: