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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
