On 16 July 2010 14:10, Wolfram Sang wolfram@the-dreams.de wrote:
I am confused. Following this list only, I so far did not notice someone saying "don't tell the bug number" (ok, might be my fault), but a few times asking the question "does this patch fix an actual" bug. Also, SubmittingPatches says:
===
... Include a description ... If you're working on a bug in bugzilla, mention the bug number, and consider filing a bug if none exists.
===
I'd say that's misinformation. As for "Does this patch fix an actual bug?", I could see how that may confuse someone, but you should generally interpret that as "Does this fix a real issue in the code.", or "Are there any real applications that care about this.", as opposed to the patch making a style change, changing something that applications don't care about in practice, or only fixing a perceived bug because the patch author simply misunderstood the original code. An associated bug in bugzilla is not required for patches, and if the patch is good and gets applied it would only serve to spam wine-bugs, which is already a fairly high-volume list these days. I suppose you could open a bug if the patch gets rejected and the issue turns out to be too hard to fix though.
Maybe this is a misunderstanding of terminology? 'commit log' is for me the combination of the single-line 'header' plus the 'description', which can be multiple paragraphs. (and is usually dropped when patches are imported to the official repo. Why is that BTW?) I would agree, that the bug number should not be in the header, but having it as additional information besides the regular description should not really hurt?
If parts of the description are dropped, that's usually because they're considered superfluous. E.g., should be obvious from the patch itself, should be obvious for someone familiar with the code, etc. It should be pretty rare for a patch to need more than a couple of lines as a description. It's of course possibly that the issue you're fixing is really subtle / tricky, but in that case it probably makes more sense to document that in a comment directly in the code. Chances are though that if your patch *needs* a long description it's because it's trying to do too much at once, or tries to do it in a way that's too complicated.