https://pantsbuild.org/ logo
Join Slack
Powered by
Releasing green branches for many of the 1.2{1-8}....
# announce
e
Releasing green branches for many of the 1.2{1-8}.1 picks will be challenging. There appear to be several branches suffering from real test failures šŸ˜•.
h
I was afraid that would be the case
w
hm, yea i wouldnā€™t cherrypick back that farā€¦ i think that the convention has been to do the last three stable releases.
sorry, i just realized what all those emails wereā€¦ thought it was a github glitch
e
The user with the issue is upgrading to 1.23
w
sure. feels like they could still bump version at a time (without committing) while ignoring this particular issue?
i say convention though, because i donā€™t think we actually have rules about this
e
Yeah. It feels pretty crappy to ask that when the fix is a fix for us failing our deprecation policy.
w
k
e
I guess I was fishing for the expected state of release branches. I found, for example, that 1.25.x has legit formatting errors. I.E.: It appears releases don't go through ci, just straight cherry-picks to the origin branch,
h
Yeah, thatā€™s true, John. I think @witty-crayon-22786 we should stop straight cherry-picking. Itā€™s convenient, but results in the bitrot John is seening
w
first we would want to answer the question of how far back we support, i think.
e
Its convenient in the way pushing straight to master would be! And its worse beacuse its for a stability guaranty we made with the community.
šŸ‘ 1
w
we donā€™t guarantee back that far though. not explicitly.
e
@witty-crayon-22786 I think that's a bit not relevant when we broke our own rules. This wasn't a bug fix. It was restoring a feature that was yanked with no deprecation - and worse, with no need to.
šŸ‘ 1
h
Its convenient in the way pushing straight to master would be! And its worse beacuse its for a stability guaranty we made with the community.
Full agreement.
w
as a special case, sure. but we would say ā€œno, sorryā€ at some pointā€¦ ie, if someone identified a back compat break in 1.0.0
h
I see what Stu is saying, but I think the more important point is that our RC branches have horrible bit rot. And a major reason for this is that we directly cherry-pick, rather than opening proper PRs
w
part of the reason we have been ok with cherry-picking without a PR is that we donā€™t try to go back more than a month or so, and large picks just ā€¦ arenā€™t picked
e
We do not apply the same logic to small master commits.
šŸ‘ 1
I think we should just stop.
āž• 1
w
we donā€™t apply them to small master commits because those changes havenā€™t had any CIā€¦ when cherry-picking to a recent branch, they have just finished CI.
h
Agreed. Itā€™s also not that much more inconvenient to use a proper PR. About an extra hour due to CI The biggest inconvenience is when people donā€™t cherry-pick right away, so the releasor now has to wait for 5-6 cherry-picks to land. We should stop that too
e
I'm pretty sure I'm going to have to become part of the problem to deliver a fix for Pinterest here and that's crappy.
h
when cherry-picking to a recent branch, they have just finished CI.
Finished CI against the master branch, but not against the stable branch
e
I think convenience is not a valid thing to reference at all. We made a contract with the community in 1.0.0. We should keep the contract. Stability means a green release branch.
šŸ‘ 1
Alright - I've got enough info - we can expect bitrot since direct cherry-picks have been a thing.
w
you can expect bitrot regardless of direct picks. but yes.
the ā€œmust have green branchā€ thing applies to stable branches, absolutely. but the internet is changing beneath us, and i expect you will encounter other failures on code that old.
in the absence of 100% hermetic builds, ā€œgreen at time of releaseā€ is the best we can do
e
Yes. Those I can accept and expect. What I did not expect was broken for real branches. We have those.
w
i can say that in the case of 1.25.x, twitter was thrashing pretty hard trying to get on 1.26.x, and backported a lot of stuff
they have since forked it.
e
Afaict every release branch since shortly after 1.0 ws for / by Twitter. I can't recall the last stable branch to get a bug report / fix for / by Foursquare or Square.
w
is that relevant to pinterest in some wayā€¦?
ā€œcontributing to producingā€ the stable branch is different from consuming
anyway. sorry that itā€™s not cleaner. let me know if i can help unblock you/them
i expect that ā€œrequiring a PRā€ is related to the ā€œmust run rcsā€ discussion from earlier today.
e
I really hate this. The only thing I've been able to come up with to feel not evil is to release the older branches as rcs so that they are not picked up by normal resolves (ie pip install without --pre). So we'd have 1.21.1rc0 and never 1.21.1. Does something like that sound reasonable?
h
Yes, that does indeed sound reasonable
e
Basically trying to communicate an unstable stable release.
w
yea.
i missed the discussion with them, but they requested or need the patch in all intermediate releasesā€¦? if not, maybe we could ask them which version they actually plan on releasing/landing, and only pick there?
e
Never again. OK, I'll also update releaser docs to steer folks away from direct cherry-picks / spell out PRs for picks.
šŸ‘ 1
I did not ask about intermediates. Theyt are (attempting) 1.23. If they succeed and we don't pick the remainder - they just hit it on next upgrade. That seems bad.
h
Thanks, John. When editing the docs, if you update 1.29.x (the default version), be sure to update 1.30.x too, please. Or fine to only update 1.30.x (Reason we need 1.30.x is that it will be forked when creating 1.31.x)
w
@enough-analyst-54434: iā€™m happy to make the doc update given that youā€™re already fighting this battle.
ā¤ļø 1
had added it to my todo list after the rc discussion.
šŸ‘ 1
e
Thanks - that's be great. I was actually going to edit the "real" docs since the readme thing is still not standard until 2.0.
h
The ā€œrealā€ docs no longer exist for the release process - they live entirely on readme.io
e
Damn.
OK - well, I'll happily let someone else do it since readme interaction is clear as mud to me at this point.
w
youā€™re headed out tomorrow, right? whenever you need to disappear, put a blurb somewhere and one of us can finish tackling tomorrow (if need be)
šŸ‘ 1
e
Yeah. I'll have internet access for the next 4 days so I'll probably be hacking 2 or so nights to actually accomplish something. Its been a thrashy month.
h
Mea culpa re https://github.com/pantsbuild/pants/pull/8208: I guess I didn't consider changing console output as something that requires deprecation. I don't think we've ever formally committed to a specific form or content for pants's stdout/stderr, except for ConsoleTasks?
w
iā€™m signing off the evening, but in case it saves time, one more comment re: https://pantsbuild.slack.com/archives/C18RRR4JK/p1591834598257800?thread_ts=1591832347.247700&cid=C18RRR4JK
realistically, i donā€™t expect that they will actually land all of the version bumps. so to be clear about what iā€™m suggesting, itā€™s that if theyā€™re trying to actually land a particular version in their repository, that picking to that version and the following ones might save some time
šŸ‘ 1
any versions for which they might just sanity check without actually landing the upgrade, we might be able to skip.
anyway, iā€™ll take a look at the state of it tomorrow
safe travels John!
ā¤ļø 2
h
e
Thanks. It's confusing to say not to use 
gut cherry-pick
though. The PR branch really should be created with a cherry-pick. It's just that that cherry-pick should be done on a PR branch, not directly on the stable branch (and then pushed upstream w/o PR).
h
Oh, I see. So 1. create a new branch 2. git cherry-pick 3. open a PR Makes sense. Thanks
Okay, updated
e
OK, and - unfortunately re-updated. Is there away to revert an edit? I meant to suggest an edit to get review, but clicked wrong button. I can;t seem to find a changelog / edit history to revert and re-apply as a suggestion.
There were two issues I think. 
cherrypick
is actually 
cherry-pick
, and from everything I know, checking out a branch and then creating a new branch are two operations that have nothing to do with each other.
So I changed the checkout of 1.28.x to a fetch to get latest commits.
h
Yes, in the right side, underneath all the boxes like ā€œheaderā€, there is a ā€œpage historyā€ button
checking out a branch and then creating a new branch are two operations that have nothing to do with each other.
My thinking was so that you create the new branch with the release branch as your merge base, rather than 
master
e
Yeah, so just read up on git checkout / git branch. That is a way I've never used the two. So, that works iff your local 1.28.x is up to date. I'll see if I can find page history and revert / re-apply so you can do as you see fit.
h
Ah, yes. I think rather than trying to give the precise git commands, itā€™ll be better to say what I meant at a high level.
No worries on reverting. I can edit it. And 1.30.x is unedited for a diff. Thanks for taking a look!
e
image.png
I'm not seeing history.
h
Screen Shot 2020-06-15 at 5.59.14 PM.png
e
Huh - you must have more powers.
h
Ah, possibly because youā€™re on ā€œSuggest editsā€, rather than 
<http://dash.readme.io|dash.readme.io>
e
Am I being dumb - can I selve serve howto here?
h
Iā€™m not sure what that means, but this is the URL I use for editing: https://dash.readme.io/project/pants/v1.29/docs. Your account has the same privileges as mine according to the settings
e
Ah, admin panel. Got it.
šŸ‘ 1
By self serve I mean how can I learn on my own from docs and not bug people, Tends to be my mode.
h
Got it. The only main gotcha with self-serving the docs is that you need to be careful which version you update. If you update 1.29.x (the default version), also update 1.30.x
e
Oh wow. I mean, as a general concept having nothing to do with http servers. I like to self-serve learn. IE find documentation and figure things out from there, asking others as a last resort. Words!
h
Ah, yes, I interpreted your clarification that way. I did not read it as HTTP servers haha. Ah, sorry. Bad link. https://dash.readme.io/project/pants/v1.29/docs/welcome-to-pants Iā€™ll handle this particular case - not at all a big deal and I appreciate the reviews!
e
Ok - thanks, that did it. Bookmarked. Is the dual edit problem specific to this strange period of time or will that be with us as an ongoing problem?
šŸ’Æ 1
h
Double edit depends on the content weā€™re documenting. If weā€™re documenting a new feature, then it will only go in the newest dev docs (1.30.x) If changing docs that already exist in the main branch (1.29.x), then we need to update both the main and dev branches
e
Ok, makes sense. I think that means in normal times we only edit / create dev docs since documentation would rarely rise to the level of a cherry-pick.
Open in Slack
PreviousNext
Powered by