Please remove / block user from bugzilla

[Henri Verbeet]

On 16 July 2010 14:10, Wolfram Sang <wolfram at 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.