Re the reformatting PR, it is truly great! However...
# general
h
Re the reformatting PR, it is truly great! However I am concerned about merging such a big disruptive PR, causing merge conflicts for every outstanding change, while we're in a CI crisis and having trouble getting anything merged.
w
yea, i'd agree with waiting a bit.
less so with the "chunks" bit
but would be good to agree concretely on when it would be a good time
h
Yeah, maybe we can declare a window in which we can get a lot of outstanding changes merged, and not start any new ones (or at least, do so at your own risk).
Why not chunks?
f
I think chunks will cause more pain than in-one-go, because they will make the process of rebasing your code post-black more manual. See this comment for an explanation: https://github.com/pantsbuild/pants/pull/8391#issuecomment-538481579
I’ve done massive code base reformattings before and they’re not as scary as you would think, because you can rebase your pre-reformatting code while resolving the formatting-releated conflicts automatically.
w
yea.
i would just maybe concur on the "let's stabilize CI a bit" front, which is why i think waiting might be good.
spending the time we're spending on formatting on helping to clean up CI would be excellent
maybe assisting with the bot/retry issue if there isn't a patch for that yet?
f
spending the time we’re spending on formatting on helping to clean up CI would be excellent
While I agree 100% that fixing CI is a priority because the situation is a big workflow painpoint to contributing to pants at the moment, I don’t think it’s really opposed to the goal of removing an orthogonal workflow painpoint around manual formatting of code. Personally, being new to pants, I felt like the formatting thing was an area where I could easily contribute because it doesn’t require much contextual knowledge unlike CI stabilization, and I felt like it would be a good use of my time because it’s something where a limited time investment can yield a paper cut fix for everyone from that point on. Sounded like an appropriate hackweek goal. Whichever fire we’re putting out, there will always be more fires to put out somewhere else, so I feel like delaying merging a change that is an improvement because some other improvements are needed too doesn’t necessarily make a ton of sense to me. Absolutely amped for also making CI less flakey, though. That is an extremely worthy goal and will have a big positive impact on contributions 😄
w
The rewrite patch is definitely valuable... no doubt about it. But it's also very easy to re-generate. So finding a good low friction time to land it doesn't seem like much to ask.
1
👍 1
So, how about this: maybe let's agree to land it first thing in London's Monday morning? that should minimize impact.
@happy-kitchen-89482: ^ agreed?
h
I mean, most of my changes are all in now, so it's really down to other people with outstanding changes. If they're willing to put up with merge conflicts, I won't get in the way. But I would like to see very clear and widely disseminated documentation on how to run the formatter in a merge conflict situation.
👍 1
But I must as a matter of principle push back on the idea that these are just orthogonal improvements that shouldn't affect each other's merges... The CI issue is critical. It's slowing all other development down dramatically. Whereas this change, while valuable, is 1) unusually disruptive, as it touches a huge number of files, 2) lower priority - good formatting is a boon but it's not critical, and 3) can be delayed easily, since it's mechanical. So choosing a strategic time to land it makes sense, and that time should be after we sort out CI. Which I think we pretty much have now? Things seem better anyway.
👍 1
Anyway, let's send out a warning that this merge is about to happen, including advice for how to deal with its merge conflicts, before merging.
1
w
@happy-kitchen-89482 : Does Monday work if they do that?
h
And just to clarify why this is so entangled with the CI issue: Unfortunately Travis merges the latest master into your topical branch before running CI. I would love to turn that off, but have yet to figure out how or even if it's possible. So once this formatting change is merged, no one can push any changes to their topical branches without first dealing with the merge conflict.
1
Yeah, I think Monday is fine.
I mostly want to propagate awareness that this is not a normal change, and people will appreciate a heads up that something is about to block all their open changes, and knowledge on how to unblock.
👍 1
Once we're over that hump it'll be very easy to stay in compliance, so this is a one-time pain, but it is a pain, so all I ask is that we take whatever steps to communicate and mitigate that pain, even as we inflict it...
1
w
Totally.
f
Yes, all above makes complete sense to me 👍
finding a good low friction time to land it doesn’t seem like much to ask.
Totally agree with this, btw. I had misunderstood your initial comment as a “let’s wait for an unspecified amount of time until all CI flakyness issues are resolved”, which prompted my response. We’re all on the same page in the end 😉