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
