Quote of the week

[Posted December 5, 2018 by corbet]

IMO, the whole set of linux kernel processes are being optimised around the wrong metrics - we count new features, the number of commits per release and the quantity of code that gets changed. We then optimise our processes to increase these metrics. IOWs, we're optimising for speed and rapid change, not quality, reliability and stability.

We are not measuring code quality improvements, how effective our code review is, we do not do post-mortem analysis of major failures and we most certainly don't change processes to avoid those problems in future, etc. And worst of all is that people who want better processes to improve code quality, testing, etc get shouted at because it may slow down the rate at which we change code. i.e. only "speed and quantity" seems to matter to the core upstream kernel development community.

— Dave Chinner

Quote of the week

Posted Dec 6, 2018 12:35 UTC (Thu) by NAR (subscriber, #1313) [Link] (3 responses)

I'm afraid software development (despite all of the methodologies) is still basically a trial-and-error process - the faster I can make a change, the faster I can fail and go to an other solution that might not fail. So it is important to make the process fast.

Quote of the week

Posted Dec 6, 2018 18:39 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

That works if testing reveals the mistakes quickly enough that others don't build on top of the flawed change.

Quote of the week

Posted Dec 7, 2018 16:52 UTC (Fri) by edeloget (subscriber, #88392) [Link]

Creating such metrics is not really hard : it's just a matter of fetching the Reviewed-by and Tested-by tags in the kernel commits.

But then, the challenge is to find these tags in the kernel commits :)

Quote of the week

Posted Dec 9, 2018 4:44 UTC (Sun) by alonz (subscriber, #815) [Link]

One could argue that, as a minimum, patches must not be considered "stable" until they have actually been released in n>=1 non-rc releases. (And I can certainly see valid arguments, given the current lack of testing, to make this "n" at least 2-3.)