📖 book: drop outdated note about removed e2e test func

[sbueringer]

Signed-off-by: Stefan Büringer [email protected]

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

[sbueringer]

I don't know when it has been removed, but it doesn't exist anymore

[fabriziopandini]

nice catch!
/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 2cb44ff248472678d70d9caa58cbd735b5a3c0df

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fabriziopandini]

/cherry-pick release-1.3

[k8s-infra-cherrypick-robot]

@fabriziopandini: once the present PR merges, I will cherry-pick it on top of release-1.3 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.3

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fabriziopandini]

not sure if we should cherry pick also in 1.2
@sbueringer ?

[k8s-infra-cherrypick-robot]

@fabriziopandini: new pull request created: #7818

In response to this:

/cherry-pick release-1.3

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sbueringer]

not sure if we should cherry pick also in 1.2 @sbueringer ?

I would personally only backport the book into 1.2 for must-have documentation updates (I'm assuming that most users only read our "current' book). But absolutely no objections if you want to.

[fabriziopandini]

I would personally only backport the book into 1.2 for must-have documentation updates (I'm assuming that most users only read our "current' book). But absolutely no objections if you want to.

I kind of agree, but unfortunately, we don't have currently a good definition of "must-have documentation updates".
might be it will be enough to specify in our backport policies that we backport document changes only to the current version of the book (backport to older releases can be exceptionally approved by maintainers under case-by-case evaluation), or something similar

[sbueringer]

Good point.

I'll think about it and open a follow-up issue or PR.

I think there also might be a difference between:

• the kind of changes we (as maintainers) kind of guarantee that we cherry-pick automatically vs.
• the kind of backports we would merge if someone opens a PR for it

But probably doesn't help as it makes it more complicated if we differentiate between those cases in our policy :)

[sbueringer]

@fabriziopandini sorry edited my comment while you were reading it :)

[fabriziopandini]

@sbueringer PTAL #7823