A half-hour slot was set aside for lightning talks, but, for all practical
purposes, lightning struck only once. The resulting session on the
linux-kernel mailing list was perhaps the most contentious of the day,
The discussion started with a complaint about people who do not trim quoted
text in responses sent to the list. It can be very frustrating to scroll
through pages of quoted text, only to find a single-line reply which,
perhaps, is not even all that interesting. Developers were urged to do
better, but it was acknowledged that the main offenders were not to be
found in that room. There was some talk of filtering overly quote-heavy
mail at the vger mail server. The filtering of top-posted replies was also
requested. Christoph Hellwig asked that originators of offending mail
receive in return an "instructional video" on email etiquette.
Hugh Dickins questioned the value of the "post early, post often" mantra.
In particular, the "post often" part gets tiresome when developers
continually repost a massive, multi-part patch series with minimal (or no)
changes. It would be nice, he said, if some of these people put their
effort into posting fewer, but more correct versions of their patches.
Alan Cox said that many of these large patch bombs come from vendors that
don't always take the hint that their work is not destined for the
mainline; perhaps that information needs to be conveyed more forcefully at
One thing that can help is for developers to put their work into a git
tree, and to post incremental patches. The git tree is then available for
reviewers who want to look at the whole series. Another helpful hint was
to avoid reposting an entire patch series in response to a single comment.
Instead, the reposting should be delayed for a while to allow further
comments to come in.
Linus said that he is not particularly bothered by the patch postings; it
is, instead, all the other noise which is irritating. He would really like
to see fewer comments on issues like white space. That's especially true
for the people in the room; when prominent developers jump into a
particular discussion, others tend to follow.
White space comments are clearly the source of a great deal of irritation
in general. Some developers questioned the value of a focus on white
space, especially for infractions (such as white space at the end of a
line) that cannot even be seen. It was suggested that some of the related
checks could be taken out of checkpatch.pl as a way of reducing white space
flames. Another alternative would be to shunt code with white space
problems into the staging tree; people who complain about white space could
then be encouraged to submit patches fixing the problems instead.
From there, the discussion touched briefly on the topic of subsystem
lists. Some developers dislike these lists; they would prefer that all
kernel-related discussion happens on linux-kernel. That sentiment is not
universally shared, though; developers who work on quieter,
subsystem-specific lists tend to prefer the more tranquil experience on
offer there. David Miller offered the creation of a linux-firehose
list which would carry messages sent to any other list served from vger.
Advocates of the single-list approach could then subscribe to
linux-firehose and be happy.
There were grumbles about messages sent to the list by robots, and by the
"tip-bot" in particular. This robot informs linux-kernel about commits to
some branches of the "tip" tree maintained by Thomas Gleixner, Ingo Molnar,
and Peter Anvin. Tip-bot postings are meant to address criticism that code
merged through the tip tree has sometimes never been seen on any mailing
list, and to provide a convenient anchor for discussions of specific
patches. They are not popular, though, and some developers asked that no
automatically-generated mail be sent to linux-kernel.
What quickly became clear, though, is that there is a certain amount of
irritation caused by the tip tree in general. Developers complained that
it is a conduit for a lot of broken code into the mainline, and that
patches merged through tip tend to create problems in far-ranging parts of
the kernel. This tree, people complained, moves too fast and with too
little caution; could it please slow down?
Ingo Molnar, the main force behind the tip tree, was not there to defend
his work; Linus was fairly strong in his defense, though. He sees Ingo as
being in a position that he (Linus) was in some years ago, and Ingo is
getting some of the same criticisms. According to Linus, slowing down is
not really possible; the code is out there, and ignoring it will not make
it go away. Ingo is doing a lot of work on core code; that work will, by
its nature, break things in other parts of the kernel at times. In the
end, Ingo's job is harder than that of other subsystem maintainers; his
critics should take that into account. Linus said that Ingo is doing a
good (and improving) job in this area, and that there were few people in
the room who could do it better. That pretty much ended the complaints
about the tip tree.
Thomas Gleixner added that the automated testing done on the tip tree has
recently been expanded to include boot testing of six non-x86
architectures. With any luck, that should help to find some of the
problems which only affect other types of systems.
Next: Generic device trees
to post comments)