<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 January 2017 at 10:53, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 12 January 2017 at 20:52, Jonathan Coe via cfe-dev<br>
<span class="gmail-"><<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> Issues have been reported in <a href="https://reviews.llvm.org/D26082" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D26082</a> which I have<br>
> locally reproduced.<br>
><br>
> What's the best course of action?<br>
<br>
</span>Hi Jonathan,<br>
<br>
This is before we branched, so whatever action we take need to be<br>
back-ported to the 4.0 branch.<br>
<br>
Adding Hans FYI.<br>
<span class="gmail-"><br>
<br>
> I can revert the change until problems are fixed. I don't think libclang's<br>
> Python bindings tests get run as part of CI.<br>
<br>
</span>Is this affecting buildbots or some kind of external CI?<br></blockquote><div><br></div><div>I've not seen any failures due to this, I don't think python tests get run.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It seems to me that we should test Python's bindings as a standard CI<br>
run, if they're added in Clang in any way.<br>
<br></blockquote><div><br></div><div>Sounds like a good idea, I'd be keen to be involved with this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm not proposing running Python itself, as that can be hard to match<br>
system expectations, but some kind of unit test to make sure the<br>
bindings are correct on all supported versions of Python would go a<br>
long way of avoiding this scenario in the future.<br>
<br>
As to revert vs. not revert, it depends on what's broken and how quick<br>
is the fix. The questions I always ask myself are:<br>
<br>
1. Is the breakage stopping any CI look from reporting further bugs?<br>
This also depends on how often the CI loop runs and how much relies on<br>
it.<br>
2. Is there someone looking at the problem? If no, then reverting it<br>
the *only* course of action. If yes, we'll need time-frames for a<br>
possible fix before deciding to revert.<br>
<br></blockquote><div><br></div><div>I'm not confident that I can patch this quickly.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If we hadn't crossed the branch barrier, I'd be all for reverting it.<br>
But we have. So, to avoid multiple reversions and re-applies and<br>
multiple RCs, I think we need to be a bit more cautious here.<br>
<br></blockquote><div> </div><div>As a point of information, before this patch clang bindings in python3 would segfault. Behaviour of bindings in python2 is unaffected by the patch.</div><div><div><br></div></div><div>best,</div><div><br></div><div>Jon</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>