Re: [PATCH 00/13] [RFC] Rust support

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

Hi Nick,

On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> This is a much different process than drafts thrown over the wall.
> What hope do any kernel contributors have to participate in the ISO
> WGs, other than hoping their contributions to a draft foresee/address
> any concerns members of the committee might have?  How do members of
> the ISO WG communicate with folks interested in the outcomes of their
> decisions?

For WG21, several folks write trip reports of each meeting, and you
can check the status of papers in GitHub at
https://github.com/cplusplus/papers/issues.

For WG14, there are way less papers going on. It is more or  less easy
to follow by reading the list of latest additions in the first pages
of the draft, as well as the Editor's Report.

> The two processes are quite different; one doesn't require "joining a
> national body" (which I assume involves some monetary transaction, if
> not for the individual participant, for their employer) for instance.
> (http://www.open-std.org/jtc1/sc22/wg14/www/contributing which links
> to https://www.iso.org/members.html; I wonder if we have kernel
> contributors in those grayed out countries?)

They are indeed very different processes. Being an ISO standard has
advantages and disadvantages.

In any case, I should note that not everyone that goes to the meetings
pays, e.g. some go as guests, some are funded by their country (or the
EU or other organizations), etc.

In fact, the bigger costs, in my experience, are the time commitment
(a week several times a year) and the costs of traveling (before the
pandemic, that is).

Furthermore, contributing proposals does not actually require
attending the meetings nor joining the committee -- some people
contribute to the standards via proxy, i.e. somebody else presents
their proposals in the committee.

> It was always very ironic to me that the most important body of free
> software was subject to decisions made by ISO, for better or for
> worse.  I would think Rust's RFC process would be more accessible to
> kernel developers, modulo the anti-github crowd, but with the Rust's
> community's values in inclusion I'm sure they'd be happy to accomodate
> folks for the RFC process without requiring github.  I'm not sure ISO
> can be as flexible for non-members.

Well, the kernel already ignores the C standard here and there. ;-) In
the end, it is "just" a standard -- the kernel and compilers can do
something else when they need.

> Either way, I think Rust's RFC process is something worth adding to
> the list of benefits under the heading "Why Rust?" in this proposed
> RFC.

The Rust RFC process has indeed upsides. It is very dynamic and easy
to participate, and allows for anybody to easily comment on proposals,
even anonymously. But, for better or worse, does not lead to an ISO
standard (which some people & companies really value, e.g. as
requirements in contracts etc.).

In the end, writing an RFC is similar to writing a paper for ISO. The
bigger differences, as mentioned above, are on the requirements if you
actually want to go there and present the paper yourself and/or if you
want to have voting rights etc.

Personally, I think some ISO policies could be improved for some types
of standards (or at least let WGs relax them to some degree), but...

Cheers,
Miguel