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
Reply to: