i.e. when shall we add/remove a presubmit job from queue blocking
cc @spiffxp I remember you have mentioned similar topic, not sure if it's documented anywhere
This is basically about
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
this is recently relevant to @shyamjvs with scalability presubmits for example
/remove-lifecycle stale
I know there was a discussion around this, and some initial attempt to document, but we should get that finalized and committed somewhere official..
/milestone 1.12
/assign @spiffxp
assume you have the most ideas here
/milestone v1.13
OK for really reals this time :P
/remove-help
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
/remove-lifecycle stale
/lifecycle frozen
/milestone v1.14
FYI @BenTheElder @fejta
Oh look, another milestone bump. The deal is that I'd like for us to implement measurement and enforcement of the criteria laid out for release-blocking. I would then expect merge blocking criteria to be basically the same, but with tighter numbers.
We also have aspirations to move away from the use of clouds in merge-blocking jobs, in the spirit of failing fast, and deferring the slower/flakier jobs later. The difficult balance here is this harkens back to the bad old days where slow/flaky postsubmit builds blocked the queue, which caused much pain for everyone.
/milestone v1.15
/milestone v1.16
/sig testing
/sig release
/remove-lifecycle frozen
/cc @BenTheElder
FYI @kubernetes/ci-signal
/milestone v1.20
Maybe we can do this before the 3 year anniversary? (because adding a milestone has _totally_ made this happen in the past)
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
/remove-lifecycle stale
/milestone v1.21
Nope. Fourth year's a charm.
Most helpful comment
/lifecycle frozen
/milestone v1.14
FYI @BenTheElder @fejta
Oh look, another milestone bump. The deal is that I'd like for us to implement measurement and enforcement of the criteria laid out for release-blocking. I would then expect merge blocking criteria to be basically the same, but with tighter numbers.
We also have aspirations to move away from the use of clouds in merge-blocking jobs, in the spirit of failing fast, and deferring the slower/flakier jobs later. The difficult balance here is this harkens back to the bad old days where slow/flaky postsubmit builds blocked the queue, which caused much pain for everyone.