Re: Potential topics for the 2021 Maintainer's Summit

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Ted,

On Thu, Sep 23, 2021 at 01:18:11AM -0400, Theodore Ts'o wrote:
> 
> After discussions amongst the program committee, and looking at some
> of the discussions to date at the LPC and the Kernel Summit, we've
> come up with the following potential topics for the Maintainer's
> Summit.
> 
> This is not the final agenda.  We are soliciting suggestions and
> comments about these topics.  Is there anything we are missing?  Is
> there something you think wouldn't be productive for us to discuss?
> 
> 
> 		  Potential Maintainer Summit topics
> 
> * Reviewing how we reacted to the University of Minnesota issue
>     After Greg K-H gives a non-technical summary of what
>     happened, and we would have a discussion about what should be
>     done differently next time.
> 
> * User-space requirementrs for accelerator drivers
>     There was some good discussion on the ksummit list, but there still isn't
>     a clear consensus of what the policy should be.  From Jon's message
>     kicking off that thread:
> 
>     - Under which circumstances should the kernel community require the
>       existence of freely licensed user-space code that exercises all
>       functionalities of a proposed kernel driver or feature?
> 
>     - Are there internal kernel interfaces, such as DMA-BUF or P2PDMA, that
>       are only available to drivers with a free user-space implementation?
>       Do we need an EXPORT_SYMBOL_USERSPACE_GPL()?
> 
>     - What constitutes an acceptable user-space implementation in cases
>       where these restrictions apply?

Just a quick comment on this. if it can be useful information, I'd be
happy to briefly explain and answer questions about the ongoing effort
to build a camera stack for Linux. We're running into the exact same
issues, and have been trying to build bridges with SoC vendors over the
past few years (with various levels of success).

> * Acceptance criteria of patch sets
>     The discussion over the folio patch set seems to be making forward
>     progress, but it's not the only case where we've had some disagreements
>     over large code contribuions: ntfs3 and ksmbd come to mind.
>     Also from the kernel summit, see slide 10 ("Upstreaming Agony) at: 
>     https://linuxplumbersconf.org/event/11/contributions/964/attachments/802/1511/Ksummit%20%283%29.pdf
> 
>     "We want to upstream everything. It makes Linux better and our lives easier.
>     However:
>     * High variability in maintainer responsiveness
>     	 * Some subsystems are really great
>     	 * Some armitecture maintainers are not as easy to work with
>     	 * Some subsystems are just stuck (e.g. memory management)
>     * Replies often come with “helpful” suggestions of radical product redesign
>          * E.g. preempt count passthrough for VMs to improve scheduling of
> 	   guests
>     * Plus usual stuff, e.g. “oh sure we can apply this two liner… *after*
>        you rewrite the subsystem”
>     Wishlist:
>     * Consistent maintainer responsiveness and acceptance criteria
>         * A maintainer CoC or expectations doc?
>     * More data driven decision making (e.g. which benchmarks are generally
>       agreed to be important for each subsystem)
>     * More openness to experimentation
>         * How can we enable this?"
> 
> * Rust in the Kernel
>     We could potentially invite Miguel so we can give him feedback, concerns,
>     etc. regarding Rust in the kernel.  In particular, Miguel asked
>     some questions at the end of his talk at the Kernel Summit:
>     https://youtu.be/mF10hgVIx9o?t=15245
>     for which feedback from the maintainers might be helpful --- if
>     we are ready to give an opinion, which is not clear.
> 
> * Is Linus happy/unhappy with the development process of Linux?
>     Anything else we need to discuss or address?
> 
> 
> Also, this is the current list of invitees to the Maintainer's Summit
> (including sponsored attendees).  As we finalize the topics, there may
> be one or two additional invites.  (For example, if we do decide to
> pursue the Rust in the kernel topic, we would need to invite Miguel,
> assuming he would be available on Friday.)
> 
> Al Viro
> Alex Deucher
> Alexei Starovoitov
> Andrew Morton
> Arnd Bergmann
> Bjorn Helgaas
> Borislav Petkov
> Chris Mason
> Christoph Hellwig
> Damien Le Moal
> Dave Airlie
> David S. Miller
> Greg Kroah-Hartman
> Ingo Molnar
> Jakub Kicinski
> Jens Axboe
> Jon Corbet
> Kees Cook
> Linus Torvalds
> Mark Brown
> Martin K. Petersen
> Michael Ellerman
> Rafael J. Wysocki
> Sasha Levin
> Stephen Rothwell
> Theodore Ts'o
> Thomas Gleixner
> Vasily Gorbik
> Will Deacon

-- 
Regards,

Laurent Pinchart