Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust]

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

On Wed, Jun 22, 2022 at 02:01:02PM +0200, Linus Walleij wrote:
> On Wed, Jun 22, 2022 at 12:58 PM Laurent Pinchart wrote:
> 
> > This doesn't mean that all concerns should be ignored, and I read most
> > of them more as constructive feedback trying to find solutions than just
> > attempts to stall progress here. For instance, I see a widespread
> > concern that, as rust spreads in more places through the kernel, it will
> > generate extra work for people who are not able or ready yet to handle
> > this. This can be handled in two ways: we can ignore that concern, and
> > deal later with the potential conflicts it could generate, or we could
> > try to address it already.
> 
> I agree. My first reactions to Miguel's and Wedsons Rust patches were
> not the most enthusiastic either, more along the lines "you think you
> can do better than 50 years of C?"
> 
> Then I looked closer and saw how Rust is designed to join imperative
> and functional programming to get the best of all worlds, to use the
> latter to solve some of the problems with the former. So now I am
> theoretically convinced that it will add real value.

I think the theoretical technical value has been sold properly now. I
see less push back on that alone, more about whether the pain is worth
the gain.

> > Could the second option be extra work to handle an issue that may not
> > materialize ? Yes, of course. I see it more as an opportunity myself.
> > For instance, we could address that concern by creating and advertising
> > a support channel for developers and maintainers who need help dealing
> > with rust impacting their work (e.g. when doing tree-wide reworks) could
> > get help, and making sure we'll have a few rust-in-linux maintainers
> > there who can provide support (it could be a mailing list, an IRC
> > channel, ...).
> 
> Why not both.

I'd rather have both indeed. In some cases e-mail works best, but when
you're actively working on a task and hit a roadblocker, being able to
get help immediately is much better. This is especially true if we want
to take the psychological aspect into account, I think it would be
crucial here to offer very quick support for the first few problems a
developer or maintainer will encounter. Not that it should become sloppy
after that, but I think people will be much more likely to try and find
a solution by themselves if they have been helped before and know
support is available than when they hit the first issue.

> https://lore.kernel.org/rust-for-linux/ <- this exists!
> I bet Miguel has an IRC channel as well.

It's even better if no new process has to be put in place, then all that
remains to do is properly advertise this to ensure that nobody will miss
it. Is there a way we could get those resources advertised when hitting
a rust-related build failure for instance ?

> > Not only would it send the message that the rust-in-linux
> > community listens to concerns and cares, but it would also result in
> > having a useful support resource from day one, as well as showing that
> > this project really has the means it requires to move forward.
> 
> I agree. What I pointed out to Miguel & Wedson was that I expect commitment
> of a personal type, what you once said (at a conference) required to
> have kernel development in the open in your DNA. To feel personally
> responsible. In clear: I expect the Rust-in-linux people to keep reading
> the mailing list and respond to questions even if they no longer have
> funding, even if it is not their current dayjob. The task will become too
> important on a personal level to be left on the roadside.
> 
> The role model for that is Torvalds working at Transmeta a few years
> back and not losing focus on Linux. That is a social responsibility that
> goes beyond the dayjob. This request is probably more than a little
> intimidating, but it is what we are looking for. If one does not find it as fun
> and rewarding as to go to such lengths, then one should not go and
> change core kernel infrastructure.
> 
> So it does not need to be a lot of people, but it needs to be dedicated
> people. Such as the people who made Kasan, which we accepted
> pretty quickly and we were not too conservative about Kasan despite
> it being so intrusive.
> 
> > > My biggest worry is that the kernel community can become irrelevant
> > > for young people as a demographic. Young people like things like
> > > Rust and web-based merge requests on github. They are also very
> > > smart. So I see it as partly an inclusion problem.
> >
> > If you put rust and github in the same bag, you'll drastically increase
> > the size of the mob that will chase you with pitchforks :-)
> 
> Ha ha I know. But I have seen many beautiful projects on GitHub,
> especially PostmarketOS, as a review tool it still lacks compared to email.

-- 
Regards,

Laurent Pinchart