Questions for the Technical Advisory Board

The nature and role of the Linux Foundation's Technical Advisory Board (TAB) is not well-understood, though a recent LWN article shed some light on its role and history. At the 2025 Linux Plumbers Conference (LPC), the TAB held a question and answer session to address whatever it was the community wanted to know (video). Those questions ended up covering the role of large language models in kernel development, what it is like to be on the TAB, how the TAB can help grease the wheels of corporate bureaucracy, and more.

Dan Williams opened the session by reminding everyone that the TAB has no formal authority to do anything — but, being composed of people who have spent years demonstrating leadership in the kernel community, it has a lot of influence and experience. The primary role of the TAB is to be a group of people who can be asked what "Linux" thinks about something, and have a reasonable chance of coming to an answer that the community will be happy with. With that in mind, he called for questions.

At the time of the talk, the TAB consisted of Sasha Levin, Jonathan Corbet, Steven Rostedt, Dave Hansen, Shuah Khan, Williams, Kees Cook, Ted Ts'o, Miguel Ojeda, and Greg Kroah-Hartman — the last of whom could not be there for the conference. Keen-eyed readers will notice that Ts'o and Ojeda don't appear in the photos below; they arrived after the others, and I failed to get them in the group shots.

Large language models

An audience member asked whether any of the members of the TAB had explored using AI in their workflows, and whether they had found it helpful. Levin answered that some people had brought up their experiences at the Maintainers Summit a few days prior — "it was mostly positive, but there were some concerns." AI is evolving quickly, he said, so it's hard to set a firm policy at this point. Rostedt said that he thought there was a lot of fear of the unknown here, but that most of the actual conversations so far have ended up favoring a wait-and-see approach.

Kees Cook thought that the recent review work was potentially going to be quite helpful for addressing maintainers' workloads. Corbet had a more jaundiced view: "I see a lot of the less pleasant sides of the AI thing, [...] trying to keep LWN.net running." He also reminded everyone of the problem with becoming dependent on proprietary tools, such as happened with BitKeeper. "I asked Linus if he would go off for a weekend and create a replacement system. He said yes, but I'm not sure if I believe it."

Khan said that AI was making it increasingly difficult to screen mentorship candidates, but that she was optimistic about the utility of automatic patch review. Hanson pointed out that, although people often think of using large language models to write code directly, generating code is "a very different thing than using AI in your workflow." He found using AI to find the right sections of AMD and Intel CPU documentation (which can run to thousands of pages) helpful.

The role of the TAB

Another question was about the role of the TAB — is it meant to be a bridge between the Linux Foundation and the kernel community? How much of the TAB's work involves the Linux Foundation? A lot more of the TAB's work is directly with the community now, Rostedt said, compared to the first days of the TAB. Ts'o clarified that when people say that the TAB does outreach to the Linux Foundation, that also means outreach to the members of the Linux Foundation. For example, the TAB published a Linux kernel contribution maturity document to encourage companies to allow their employees participate in community work while on the clock. That has a lot of benefits, he said, in reminding the companies that they should send people to LPC, dedicate time to reviewing patches, and so on.

Levin pointed out that the TAB also finds ways that the Linux Foundation can help the kernel community, and oversees LPC. Khan gave the example of getting a professional mental health speaker to present at LPC a few years ago to help support maintainers struggling with burnout. "We're the interface layer, within our own community and the Linux Foundation," Cook summarized.

Williams said that the TAB's work is "kind of interrupt-driven". When a company has a question for "Linux", or when a kernel developer has a need that requires some kind of perceived authority to handle, that's when the TAB steps in. The power of the TAB comes from the fact that the members have done work and shown leadership in the past, Ts'o said. Electing the members of the TAB is really just a recognition of that leadership; elevation to the TAB doesn't grant special powers, but it does make it obvious that people should come to you with problems when they don't know who to ask.

A lot of the TAB's meetings are just about coming to a consensus on different topics so that they have answers ready to go to upcoming problems, Williams said. "And we disagree a lot, too, which is a good thing," Levin added — only for Williams to insist: "No we don't!" Khan clarified that when the TAB does disagree it's "with respect"; their disagreements represent the community as a whole.

Elections

Williams then posed a question to his fellow TAB members: with the (recently closed) TAB election, what do they want to see next year? What should the TAB be looking at? And for the non-TAB audience members: what conversations can the TAB drive that would help you in your work?

Levin opined that the TAB is at its best when it's boring: it only becomes exciting when something's going wrong. Williams said that he thought the TAB should be helping people figure out how to talk about kernel deadlines and schedules to their management chains: "Some of you promise kernel deadlines — does there need to be a discussion about that? Can the TAB help?"

Cook thought that was an interesting topic, and maybe worthy of an extension to the contribution maturity model document. A member of the audience asked about a specific case that he had run into trying to add LLVM code-coverage (llvm-cov) build-options: the kernel already supports gcov and kcov, but llvm-cov offered some non-overlapping features that he needed. The maintainer saw that there was (potentially) a lot of common support code between gcov, kcov, and llvm-cov, and told him to go away and refactor things to have a single code-coverage interface, instead of just adding llvm-cov into things. Ojeda agreed that this kind of situation was definitely a place where the TAB could help manage expectations on all sides.

Khan said that there were two aspects to the problem of being asked to go and do a bunch of supporting work for a change: justifying schedules to management, but also the problem of balancing an employer's interests against community interests. The community wants to see things that benefit Linux in the long term. Ts'o thought that having pressure to get things upstream was "in some ways a great problem to have," since it's an indication of the kernel's success. When a maintainer pushes back against something like llvm-cov, that's often driven by a worry about drive-by contributions, he said. The members of the TAB have experience explaining these things to different stakeholders.

That is really what the TAB is at its core, Levin added:

Ten people who want to help the community. And you folks don't use that as much as you should. You can email us, email the TAB mailing list. We don't promise we can fix it, but we're here to help.

Politics

One member of the audience spoke up with "less of a question, more of a hope": as polarity and divisiveness grow in different parts of the world, they hoped that the TAB would continue to support the Linux community in showing that collaboration works. They specifically cited the recent banning of some Russian maintainers as something that could have been better.

Corbet echoed their worry, saying that he was also concerned about the feasibility of having technical conferences in the US. Many people don't want to go there — for good reason — and many people can't leave, he said. "That's going to be a hard one for us to navigate." The TAB's guiding principle in cases like this, Ts'o said, is "what is best for the community?". It isn't about whether we believe a given sanctions regime is correct, he said, it's about how we get the community together. Sometimes that's not something that the TAB can control, and they just have to try to make the best out of a tough tradeoff.

Promotions

Most kernel developers work in big companies, Hansen said. How does one go about mapping the things one does in the community to the things that one's company wants, he asked? Williams suggested that being elected to the TAB might be good for one's promotion chances, to general laughter. Rostedt said that he'd actually never been promoted while at a company, but that he had frequently been hired away for a higher position. Sometimes other companies can see the benefit of kernel work more strongly than someone's current employer.

Hansen agreed that the mobility of kernel work was a nice benefit — when he walked into Intel, he already knew several people there from conferences and from kernel work, he said. Ts'o said that he's been trying to promote the idea that it's useful for companies to reach out and get recommendations from senior open-source developers for anyone going up for promotion. That's something that individual employees can do too: "See if your company can accept letters of recommendation for your promotion packet." Hansen added that writing letters of recommendation was something that the TAB could help with. Ojeda said that he'd written just such a letter for a student last week, so that can help with academic careers as well as corporate ones.

Time commitment

Another member of the audience asked how much time per week or per month being on the TAB required. Ojeda answered that there's a one hour meeting every month, plus time spent on emails, but it's generally not too much work. Levin said that when it becomes "exciting" there can be additional work. Cook likened it to working on multiple patch series — sometimes a patch series will be small, sometimes big, but one can generally fit it in around other kernel work.

Ts'o said that many times, people join the TAB because they're passionate about contributing to the community, in which case they will find additional work to do. So, being on the TAB can blend into time spent on other community work. When he ran for the TAB, Rostedt said, it was because there was tension between systemd folks and kernel folks, and he wanted to be on the TAB to have resources to bring the community together. Getting elected let him talk to the Linux Foundation about obtaining funding for systemd developers to attend kernel events and vice versa.

At that point, the time allocated for the session was nearly over; Williams brought up one final item: Corbet has been a constant on the TAB. He has always had our back, Williams said. And after 18 years, he has decided to step away. Williams called for a round of applause, which quickly manifested.

[ Thanks to the Linux Foundation for enabling my travel to Tokyo to cover the Linux Plumbers Conference. ]

Index entries for this article
Conference	Linux Plumbers Conference/2025

---

to post comments