Ok, i see your argument.
Is there any other way for us to get the benefits of the impact
line, without actually adding one?
They are:
- Better split-up patches from contributors.
- Increased maintainer and developer attention on the effects of
patches.
- Less time we have to spend on patches we get with impact-lines.
Both hpa and me reported this.
- easy regression post-mortems
What i dont understand is how you can dismiss these positive points
so easily and only concentrate on the negative points - these
effects are mostly visible to those creating impact lines - not to
you. You cannot really have seen any of these effects without having
done impact lines for a few days.
(
Okay, you are perhaps an exception, you _do_ write fantastic
commit logs that generally need no 'stinkin impact line.
There's exceptions though, even with your commits. I wish you had
added one to ea34f43a for example, which you committed today.
It is not clear from that commit log at all what the practical
relevance of your fix is.
I suspect it fixes Ali Gholami Rudi's problem of his CPU hitting
50^C till the fan turns on.
I'd probably have added the following impact line (although i'd
have first asked Ali whether this is the precise impact the fix
had on him - it's not 100% clear from the discussion):
Impact: fix cpufreq misbehavior causing high CPU temperature
Does this information matter? I think it does. Does it matter
_more_ than the rest of the commit log? I think, to most Linux
users, it does. That's one of the reasons why we are experimenting
with formalized this kind of information. It's important
information and it should not be forgotten from commit logs.
As a developer, while writing up a commit log it is _so_ easy to
get lost in the details of the 'how' and 'why' - and not emit
basic information: why do people care? What were the bad
_practical_ effects of the bug that are fixed here?
It is basic human nature to get lost in that - even for the best.
)
Ingo
--
