Hi,
On 2020-04-28 13:56:23 +0900, Michael Paquier wrote:
> On Mon, Apr 27, 2020 at 07:48:54AM -0700, Jesse Zhang wrote:
> > Are you expressing a concern against "churning" this part of the code in
> > reaction to upstream LLVM changes? I'd agree with you in general. But
> > then the question we need to ask is "will we need to revert this 3 weeks
> > from now if upstream reverts their changes?", or "we change X to Y now,
> > will we need to instead change X to Z 3 weeks later?".
>
> My concerns are a mix of all that, because we may finish by doing the
> same verification work multiple times instead of fixing all existing
> issues at once. A good thing is that we may be able to conclude
> rather soon, it looks like LLVM releases a new major version every 3
> months or so.
Given the low cost of a change like this, and the fact that we have a
buildfarm animal building recent trunk versions of llvm, I think it's
better to just backpatch now.
> > In that frame of
> > mind, the answer is simply "no" w.r.t this patch: it's removing an
> > #include that simply has been dead: the upstream change merely exposed
> > it.
>
> The docs claim support for LLVM down to 3.9. Are versions older than
> 8 fine with your proposed change?
I'll check.
> > OTOH, is your concern more around "how many more dead #include will LLVM
> > 11 reveal before September?", I'm open to suggestions. I personally have
> > a bias to keep things working.
>
> This position can have advantages, though it seems to me that we
> should still wait to see if there are more issues popping up.
What's the benefit? The cost of checking this will be not meaningfully
lower if there's other things to check as well, given their backward
compat story presumably is different.
Greetings,
Andres Freund