Re: Patch format
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 log is a journal / diary which describes a sequence of
changes over time. 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.
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.
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.
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.
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. The main important thing here is not the history but
the reason and other meta information
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. This
is just a different intention compared to what we want to accomplish
with the patch description.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: