So where are we at w/ cherry-picking enhancements ...
# development
h
So where are we at w/ cherry-picking enhancements once rcs have been cut? We got a bit cherry-pick heavy the past few releases, and have reflected that 2.8, 2.10, and 2.11 were too hard to land.
Case studies: • new
[python-infer]
init file handling to ease onboarding https://github.com/pantsbuild/pants/pull/15397 • bump Protoc to a version w/ M1 support: https://github.com/pantsbuild/pants/pull/15424
f
in a release train, if the feature missed the current release, it should wait for the next release.
👍 1
c
If there's not a user blocked waiting for the feature, I don't really see the urgency backporting new features/enhancements.
👍 1
w
imo, the point of these processes is to save us time and effort. so i don’t know if i subscribe to a hardline “no debating picks” approach
f
defaulting to saying “no” to a backport helps with getting the release out the door
w
bugs are clearly unambiguous. but i think that there is still room to discuss other picks.
👍 2
f
the downside is users having to wait for a subsequent release, which I submit is fine when we release on schedule which we can do if we rarely cherry pick.
w
defaulting to saying “no” to a backport helps with getting the release out the door
@fast-nail-55400: not in the train model, ironically… if it’s going to take 6 weeks to stabilize, regardless, then individual picks don’t necessarily affect that. subject to debate around how risky they are though.
@hundreds-father-404: regarding 2.11: i don’t think that we necessarily regret cherry-picking the PEX-subsetting performance enhancement. made for a better release in the end, and was work that we needed to do anyway. the only thing that was affected was whether we needed to pick those fixes somewhere… the fixes needed to happen regardless, so the thing you save is time cherry-picking. but that’s fairly automated.
👍 1
so that’s an example of the grey area.
h
My goal here isn't as much "save time", but "have the optimal experience for users". Is it better for them to have a more stable release, vs. an improved experience Both those tickets I link to at the top have that tension. E.g. I want people to have the new
inits
experience sooner. But it might destabilize the release
w
sure… it’s about risk vs reward. low risk picks are low risk, but still need to be worthwhile.
the
inits
change is somewhat risky probably… M1 change seems very low risk
relatedly: • https://github.com/pantsbuild/pants/pull/15449https://github.com/pantsbuild/pants/pull/15450 @hundreds-father-404: if you’d like to discuss any more picks to 2.12.x, let me know. but i might need to leave the 2.12.x release to John in that case, because i’ll be out of town this weekend
otherwise I'm good. I think https://github.com/pantsbuild/pants/pull/15396 is prob too risky for 2.12? Wdyt?
w
yea, and more a polish than a bugfix… #15396 can wait probably.
👍 1
ok, it looks like it’s 1 and 2 new picks respectively: i’ll keep those open and refresh them.
@hundreds-father-404: ok, updated the 2.11.x release: should be ready to go. https://github.com/pantsbuild/pants/pull/15449