https://pantsbuild.org/ logo
h

hundreds-father-404

05/12/2022, 6:04 PM
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

fast-nail-55400

05/12/2022, 6:06 PM
in a release train, if the feature missed the current release, it should wait for the next release.
👍 1
c

curved-television-6568

05/12/2022, 6:08 PM
If there's not a user blocked waiting for the feature, I don't really see the urgency backporting new features/enhancements.
👍 1
w

witty-crayon-22786

05/12/2022, 6:08 PM
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

fast-nail-55400

05/12/2022, 6:09 PM
defaulting to saying “no” to a backport helps with getting the release out the door
w

witty-crayon-22786

05/12/2022, 6:09 PM
bugs are clearly unambiguous. but i think that there is still room to discuss other picks.
👍 2
f

fast-nail-55400

05/12/2022, 6:10 PM
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

witty-crayon-22786

05/12/2022, 6:10 PM
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

hundreds-father-404

05/12/2022, 6:18 PM
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

witty-crayon-22786

05/12/2022, 6:19 PM
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

witty-crayon-22786

05/13/2022, 5:44 PM
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