|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Re: Fix quilt merge error in acpi-cpufreq.c |
|| ||Thu, 16 Apr 2009 03:46:42 +0200|
|| ||David Miller <davem-AT-davemloft.net>, hpa-AT-zytor.com,
|| ||Article, Thread
* Linus Torvalds <email@example.com> wrote:
> > You just dont seem to understand why i find it useful. You also
> > seem to try to deprive us the basic right of creating new,
> > field-specific language variants we find useful in our everyday
> > work. And that sucks.
> YOU HAVE NEVER GIVEN A COHERENT REASON FOR FINDING IT USEFUL!
> Yes, you bring up the same reason every time: namely that you want
> to know what the patch does. But never _once_ have you given a
> reason fo why that fixed-format string helps at all.
For similar reasons people have memos, stick-it's and other formal,
automated, reflex-alike daily routine measures to make sure they
dont forget to do something they all too easily forget otherwise.
If i apply a patch i always notice the ones without an impact line
(it's missing from the visual appearance of a commit - just like it
is _looking ugly_ to you - just inverted), and i dont apply one
1) convincing myself it does not need one
2) or adding one
It also sticks out like a sore thumb if it's incorrect. For example
"Impact: fix" is a bad one at a glance.
This kind of formal measure _forces_ the extraction of this very
specific type of summary on all sides of the contribution chain -
and it drastically reduced the number of commits i regretted in
It also speeds up patch processing because seeing an impact line i
only have to scan for code patterns contradicting that claim -
instead of doing general scanning figuring out the type of the patch
- then doing a second pass figuring out whether it truly matches
that expectation. I can also prioritize and order incoming patches
much easier if i have a rough expected impact analysis. If a list of
patches claims to be complex i'll put it in the appropriate section
of the day.
The number of contributors who can write meaningful changelogs or
who can be taught to write really good changelogs is very, very low.
I'd guesstimate somewhere around 5% of all Linux contributors. (The
guesstimation is probably on the more generous side.)
The central problem, as i see it, is about having people with two
- good coding abilities
- good documentation/expression abilities
Both skills are unlikely to begin with - and it is two unlikely
factors combined, and to find a person with both skills at once is
unlikely square two.
In fact they are even less likely to combine in the same person, for
the following reason: both capabilities reside in the left half of
the brain, and an over-developed skill in one activity such as
programming supresses other activities like linguistic abilities.
It happened not once and not twice to me in the past that after a
night spent coding i was unable to properly order a burger or some
other meal. I was still seeing code everywere and was thinking in
code literally - language and talking was far away.
Yes, people combining both skills still exist, and they are often
maintainers. In fact maintainers dont spent a lot of time _writing_
code, so their linguistic abilities tend to be very good. It is not
that they are not good coders - they still are - but they dont do
extreme amounts of programming that supresses linguistic skills.
So basically your argument, as i see it, boils down to the following
end result in practice: that maintainers should write all or most of
the changelogs. We simplified that down to: 'maintainers write a
single line impact summary - and try to keep the rest of the commit
as tidy as possible'. Anything more involved than that just doesnt
Show me one person _you_ actually taught to write good changelogs -
just one person who was not a natural born talker to begin with.
I'll show you a 100 other people who cannot write good commit logs.
They'll try and will limp along, but generally they cannot.
They might not even have English as their mother tongue - but still
can read and understand C fantastically.
I really dont know what the good solution and the good balance here
is, i only see a lot of conflicting requirements which look
impossible to meet.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)