<div dir="ltr">Hal,<br><div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To which message are you referring?<br></blockquote><div><br></div><div>This one: <a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-June/000146.html">http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-June/000146.html</a><br>
</div><br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To be fair, this is a bit different. First, as I've explained, you don't need approval from the code owner, you need approval from some established contributor who is knowledgeable in that part of the code, including design, implementation details and future direction (and, in effect, who is willing to take responsibility for your change). The problem you have with many of the OpenMP patches is that only the code owners are in such a position, but please don't over-generalize. There are many more qualified people for build system changes (although, FWIW, not as many as one might think). Please understand that, as far as we could tell, the future direction (CMake) was clear, and so Alp had all of the knowledge he needed to approve the commit.<br>
</blockquote><div><br></div><div>Agree -- no two things are exactly the same.<br><br></div><div>Said this, do you think reviewing and committing a new build system on a weekend, with no chance to have a review with project architect is a good and collaborative approach?<br>
<br></div><div>Really?<br><br></div><div>Andrey<span class=""></span><br></div></div><br></div></div></div>