KS2009: LKML volume and related issues

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, however.

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 times.

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

---

(Log in to post comments)