Open letter to Kubernetes reviewers/approvers (and contributors!)
Daniel Smith
Dear Kubernetes OWNER!
As you probably know, Kubernetes is currently experiencing a number of things leading to less quality than we (and our users) expect. Examples:
Regressions, due to absent or incorrect tests
Flaky tests (causes including faulty infrastructure, faulty tests, and–worst of all–faulty system)
Bugs introduced by new features
We don’t want to ask contributors to jump through too many hoops to contribute, but given the current quality of Kubernetes, we’d like to change the bar for accepting a PR from “don’t make the code locally worse” to “also don’t build on shaky foundations”.
This implies that the following are valid reasons to hold a PR:
“The existing tests don’t clearly cover important aspects of the existing code. Can you fix this in a separate PR before implementing the functionality in this PR?”
Low coverage is sufficient to merit this response, but not necessary – we expect that you, as an OWNER, likely know where the skeletons are.
“Sorry, but since right now we are emphasizing release quality, you may not ‘submit the tests in a followup PR’, we need good tests to accept changes.”
There are asynchronous aspects to this test, can you please run it with `go test -race -c $pkg && stress $pkg.test` and ensure that it’s not flaky?” (guide)
Example triggers for this: use of time.Sleep() in a test; use of mutexes etc…
Requests like this should be similar in scope (and obviously, location in the code) to the PR they are about – this isn’t the way to get someone to e.g. redesign kubelet!
We’re also extending the Test Plan section of the KEP template in the spirit of the above to ensure we will all be thinking holistically about tests for every new feature.
Thank you for your continuing care and attention to detail!
– @lavalamp, @liggitt, @wojtekt, @logicalhan, @dims, @fbongiovanni, @pohly, @alculquicondor, @derekwaynecarr, @seans3, @fabriziopandini, @johnbelamaric, @soltysh, @KnVerey, @cblecker, @deads2k, @eddiezane, @thockin, @dchen1107, @jdumars, @xing-yang
Antonio Ojea
--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@kubernetes.io.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAB_J3baTEWm8oLLX5w5B-EKw_61CtQ%2B9%3DpjRmKkdOQ5_d1Bc9w%40mail.gmail.com.
Davanum Srinivas
--
To unsubscribe from this group and stop receiving emails from it, send an email to leads+un...@kubernetes.io.
Carlos Tadeu Panato Jr
Wojciech Tyczyński
Bob Killen
Antonio Ojea
Patrick Ohly
> Anybody interested in talking more about this next Monday during the
> contributors summit?
(https://groups.google.com/a/kubernetes.io/g/dev/c/myGiml72IbM).
--
Best Regards
Patrick Ohly
Cloud Software Architect
Intel GmbH
System Software Engineering/Cloud Native
Oliver Schad
Is there
a) a list of concrete bugs available which you refer to?
b) did you and other agree on something how to improve things?
Best Regards
Oli
On Fri, 22 Apr 2022 11:13:35 -0700
"'Daniel Smith' via dev" <d...@kubernetes.io> wrote:
> Dear Kubernetes OWNER!
>
> As you probably know, Kubernetes is currently experiencing a number of
> things leading to less quality than we (and our users) expect.
> Examples:
>
> Regressions, due to absent or incorrect tests
> Flaky tests (causes including faulty infrastructure, faulty tests,
> and–worst of all–faulty system)
> Bugs introduced by new features
>
>
> We don’t want to ask contributors to jump through too many hoops to
> contribute, but given the current quality of Kubernetes, we’d like to
> change the bar for accepting a PR from “don’t make the code locally
> worse” to “also don’t build on shaky foundations”.
>
> This implies that the following are valid reasons to hold a PR:
>
> “The existing tests don’t clearly cover important aspects of the
> existing code. Can you fix this in a separate PR before
> implementing the functionality in this PR?”
> Low coverage is sufficient to merit this response, but not
> necessary – we expect that you, as an OWNER, likely know where the
> “Sorry, but since right now we are emphasizing release quality,
> you may not ‘submit the tests in a followup PR’, we need good tests
> to accept changes.”
> There are asynchronous aspects to this test, can you please run it
> with `go test -race -c $pkg && stress $pkg.test` and ensure that it’s
> not flaky?” (guide
> )
> -
> Example triggers for this: use of time.Sleep() in a test; use of
> mutexes etc…
>
>
> Requests like this should be similar in scope (and obviously,
> location in the code) to the PR they are about – this isn’t the way
> to get someone to e.g. redesign kubelet!
>
> We’re also extending the Test Plan section of the KEP template
> tests for every new feature.
>
> Thank you for your continuing care and attention to detail!
>
> – @lavalamp, @liggitt, @wojtekt, @logicalhan, @dims, @fbongiovanni,
> @pohly, @alculquicondor, @derekwaynecarr, @seans3, @fabriziopandini,
> @johnbelamaric, @soltysh, @KnVerey, @cblecker, @deads2k, @eddiezane,
> @thockin, @dchen1107, @jdumars, @xing-yang
>
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Hardstr. 46
9434 Au | Schweiz
www.automatic-server.com | oliver...@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47