Re: Patch format
Am Montag, den 19.05.2008, 13:00 +0200 schrieb Andreas Tille:
> On Mon, 19 May 2008, Daniel Leidert wrote:
>
> > Yeah, exactly. And a Changelog entry is nothing else than a change
> > description ... exactly what you try to achieve - describe, what apatch
> > does/changes.
>
> I really do not agree that a description of a patch is logically a
> changelog.
A ChangeLog is *collection* of *patch descriptions*. How do you
understand a changelog?
> A log is a journal / diary which describes a sequence of
> changes over time.
Yes. It collects patch descriptions. I referred to a single entry.
> A patch might also have a history but in most
> cases it is a single occurance and thus it can be mentioned as an
> item in debian/changelog - but it is no changelog itself in the first
> place.
What are your referring to?
> Moreover your format gives no chance for giving structured information
> like it was suggested here in "Field: Value" form like it is described
> in RFC 822.
Please read my mail. I referred to the description itself == the content
of the "Description:" field. There is no conflict with your approach to
use RFC 2822 compliant multiline fields (for whatever reason you think
they are necessary).
> > As I told in this thread I would recommend a good patch
> > description in debian/changelog (a changelog),
>
> Fully ACK.
>
> > because it is the first
> > place one will look for. And you can use the same patch/change
> > description you put in the changelog also in the patch.
>
> This is duplicated information and makes no sense in my opinion.
Why do you think, the patch *description* in the patch header and in
debian/changelog should differ? The patch might be a bit more verbose
about the patch intention and technical details (e.g. comments by
upstream or discussion citations). But debian/changelog should
definitely contain the same basic information: changed files, changed
functions and a short explanation/reasoning. This is, what makes a patch
description useful. Which information do you expect from a patch
description?
> > It makes it easy
> > to understand, where something has changed and why.
>
> I do not agree to this statement and moreover we loose the chance
> to automatically parse patch descriptions which I foresee for the not
> so distant future.
This is simply not true. You seem to misunderstand something.
> > It is just a suggestion, how a patch description could look like. If you
> > take a look at the debian/changelog files of the packages we maintain in
> > debichem, you can see, how to apply the same scheme to non programming
> > files, like e.g. Makefiles or .desktop files, ... An example:
> >
> > * Makefile.am (xml_DATA): Remove license. We ship it in
> > debian/copyright.
>
> IMHO this is a different kind of thing, because you might maintain
> this file over a long time and keeping the history of changes inside
> the changed file is a good programming habit. But this is no patch.
> A patch is (or should be) a snippet of code that is (on most cases)
> intended to be adopted by upstream and will vanish once this is
> accomplished.
Please try to see examples a bit more general:
* Makefile.in (htmldirectory): Use $(htmldir) as provided by
configure(.ac) instead of $(pkgdatadir) to install HTML docs.
This is a typical change, I would propose to upstream.
> The main important thing here is not the history but
> the reason and other meta information
Why are you referring to a "history"? If a patch changes over time, I
also expect some history information in the description. But I do not
suggest to make the Description field a Changelog. I just referred to a
well known scheme for change descriptions. Use it or not. I don't care.
I just wanted to point o this well known format.
> > Then add whatever else you need: bug report references, forwards to
> > upstream bug-tracker, comments by upstream, ...
>
> There is no need for a parsing such files for this kind of information
> by automatic tools and thus you could them put in with free text.
The suggestion contained e.g. a "Forwarded" field. Comments of upstream
IMHO belong into the description. And I also believe, that the bug
report reference belongs to the necessary information. If you put it
into an own filed or into the description .. again, I don't care. I
couldn't care less.
> This
> is just a different intention compared to what we want to accomplish
> with the patch description.
I think, you simply misunderstood my mail. But I will now turn to the
more important stuff ... fixing outstanding bugs than arguing if a
special part of a patch description should have an own field or not and
if automatically parseable fields are necessary to understand a patch.
EOD for me
Regards, Daniel
Reply to: