On 04/25/2017 08:20 PM, Boris Zbarsky wrote:
On 4/25/17 1:07 PM, Alexander Surkov wrote:
I bet there's always room for improvements, and I hope this was a counterpoint
for the example only, not for the bug organization approach.
Sort of.
It was a counterpoint to "just check the bug; all the info is there". Often
it's not there, or not there in usable form.
If people included a summary of the discussion in the bug right about when they
commit, or had bugs that actually explained what's going on clearly. I
would be a lot more OK with the "check the bug" approach.
Overall it feels with me that long comments vs check-the-bug is rather
different styles
To be clear, I don't think commit messages need to be _long_. They need to be
_useful_.
Exactly. Recently I've seen some commit messages to be long but not useful, in the style
"I did this and that", but not really explaining why.
A commit message pointing to a particular bug comment that
explains all the ins and outs is no worse, from my point of view, than a commit
message that explains the ins and outs.
A major issue comes from bugs where the work is split to several patches. That
is why bugs really need to explain it all too.
The problem I started this thread to address is things like a commit message that says "flip
this bit" and references a bug entitled "flip this bit",
with no explanation of what the bit does or why it should be flipped. I hope
we can all agree that _that_ is not OK. And it's far too common.
Yeah, definitely. The bug should be clear about what it is about to fix, and
the commit message should also be clear what it is doing and why.
In some cases bug title is clear enough to explain why something is broken or
should be changed, but not usually.
(I have perhaps a bit bad habit to file bugs with just descriptive title, especially in
case of "Consider to do foo" bugs)
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
