Strengthen Cherry Pick Guidance about community HOT 5 OPEN

I spent some time looking to see if there were industry standard defect classes like data-loss, security, performance hoping maybe we could put together a bit of taxonomy and decide which classes are valid for cherry picks. However, it seems like most alignment is around severity like critical, major, minor, etc where the highest severity issues generally include security, data-loss, and often performance regressions. I think the recommendations from the first bullet point are a great place to start.

Assuming we want labels for these, area/security kind/regression are available today but data-loss doesn't seem to have a relevant label, perhaps kind/data-loss?

from community.

Assuming we want labels for these, area/security kind/regression are available today but data-loss doesn't seem to have a relevant label, perhaps kind/data-loss?

does it mean that unless labels( like area/security ) added, the PR is not allowed to cherry-pick?

from community.

does it mean that unless labels( like area/security ) added, the PR is not allowed to cherry-pick?

I'm not sure it becomes a requirement, initially, but I believe having the labels available to track the criteria that are part of the consideration in cherry-pick approval would be helpful. As written the description just says that the author would self affirm it's one of the approved fix classes or provide other reasoning why the change needs to be backported so that the release team can make more informed decisions.

from community.

note that sometimes a fix for a user blocking bug could be eligible for a backport, but today that is just a kind/bug. at the EOD everything that is backported is a bug fix.

instead of working with the current set of labels we could create a new family of labels foo/bar, where bar must always be the resson and classification provided by the backport author and foo will be the family specific to backports. these labels could be explaned by bots, and blocking if not present (ALA needs-foo).

at the same time, ETOOMANYLABELS.

from community.

one other category of changes that seem acceptable for backports came up - 1.29.0 accidentally enabled an alpha capability by not applying the feature gate correctly... fix to apply the gate correctly is in kubernetes/kubernetes#122343

That's sort of the opposite of a regression... it's an accidental progression of functionality intended to be gated to roll out in a controlled way.

from community.