Re: [PATCH] Documentation/process: Add Linux Kernel Contribution Maturity Model

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Dec 16, 2022 at 03:14:17PM +0700, Bagas Sanjaya wrote:
> On Wed, Dec 14, 2022 at 01:57:14PM -0500, Theodore Ts'o wrote:
> > +* Software Engineers are not allowed to contribute patches to the Linux
> > +  kernel.
> 
> Software engineers turned product manager or support desk people?

Actually, what we were thinking of companies that were paranoid about
the GPL.  For example, there is a particular major hardware supplier
used by many in the Linux ecosystem where the senior management tends
to be mostly composed of patent lawyers....

(In the United States, most companies have employment contracts which
means that all intellectual output, either on or off work.  Which
means that some companies can prohibit their employees from
contributing anything to any open source project, even if the work is
done after hours on their own time.  So while "Level 0" may seem
horrific, there are software engineers in the US who are constrained
in this way.  If we can encourage those companies to move from Level 0
to Level 1, that's at least a step in the right direction.)

> > +  * The time interval between kernels used in the organization’s servers
> > +    and/or products, and the publication date of the upstream kernel
> > +    upon which the internal kernel is based.
> 
> I.e. the time for rebasing internal kernel against upstream one? For
> example rebasing against several stable minor releases (x.y.z) is easier
> than forward porting out-of-tree commits into new upstream release
> (x.y).

It's not necessarily the time to rebase the kernel.  It might take
less than, say, six years to rebase a product kernel based on 4.9 to
6.1.  But the company might decide not to expend the engineering
resources to do the work, but instead to continue shipping product or
using a data center kernel based on an antediluvian upstream release.
After all, there are many companies using RHEL/CentOS 7, whose kernel
is based on 3.10.  Yeah, with of tons of backports and (hopefully) all
of the necessary security patches, but is that really the best way to
run a railroad?

But, yes, if your point is that this metric doesn't distinguish
between an organization which is regularly keeping itself with the
very latest 4.9.336 kernel, as opposed to reguarly jumping to the most
recent LTS kernel (i.e., every year or every other years going from
5.4 to 5.10 to 5.15 to 6.1), yes that's true.

However, it may be that it's better to encourage companies to adopt an
"upstream-first" development model.  I attempted to capture this in
the metric, "number of out-of-tree commits present in internal
kernels".

						- Ted