Hi Mahesha,<br><br>I understand it may be difficult to get how things are working here, so let me explain what I have understood of it (so far). Do mind that I am mostly a lurker here so my words may be slightly off.<br><br>
There are two categories of developers working on Clang: those who are trusted and those who are not trusted *yet*. Clang is a large body of code, with many areas, so it will take time before a newcomer is comfortable in coding there and understand the implications of his work, and he/she will probably not be trusted before this happens.<br>
<br>In general, those who are trusted will commit and their patch will get reviewed after the fact; unless they want to consult their peers and voluntarily submit themselves to a pre-commit review to gather opinions (generally on the cfe-dev list).<br>
<br>Those who are not trusted yet should ask for approval before committing every time for non-trivial patches (trivial patches are for example typo/grammaro corrections); this approval will be formal (sometimes abbreviated to LGTM, other times more explicit).<br>
<br>Being new, you are not trusted yet and so will need to get approval from the code owner of the area you are working on. This approval will only be given after one or several reviews, please do not be afraid of them, it is expected that it takes time to learn new coding guidelines *and* new idioms *and* the organization and goals of each piece!<br>
<br>Because reviewing takes so much time, many people may participate, but only the code owner of the area you have been working on may deliver the final go-ahead.<br><br>Finally, the last round may not be completely "spotless", and you may get a comment such as "with those fixed, LGTM" which indicates that the code is good to go after the few fixes evoked in above. This should be the only incidence where you can commit a patch without further approval.<br>
<br>Hope this helps.<br><br>-- Matthieu<br><br><div class="gmail_quote">On Sat, Oct 27, 2012 at 1:00 PM, Mahesha HS <span dir="ltr"><<a href="mailto:mahesha.llvm@gmail.com" target="_blank">mahesha.llvm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler,<br>
<br>
I reverted back all the changes. I am sorry. I was in an impression<br>
that code is in a good shape to commit as it had went through few<br>
rounds of review. Also, I  had misread the line "Code can be reviewed<br>
either before it is committed or after"  from<br>
<a href="http://llvm.org/docs/DeveloperPolicy.html" target="_blank">http://llvm.org/docs/DeveloperPolicy.html</a><br>
<br>
Thanks for your review comments. I will go through them. And, I will<br>
wait till I get a formal approval.<br>
<br>
--<br>
mahesha<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sat, Oct 27, 2012 at 2:48 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> On Sat, Oct 27, 2012 at 2:10 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
>> On Fri, Oct 26, 2012 at 11:14 PM, Mahesha HS <<a href="mailto:mahesha.llvm@gmail.com">mahesha.llvm@gmail.com</a>> wrote:<br>
>>> Hi Dmitri,<br>
>>><br>
>>> Thanks for the review. I have taken care of all your comments. With<br>
>>> respect to the use of std::lower_bound() instead of our own binary<br>
>>> search implementation, looks like, it is *not* straightforward as the<br>
>>> search algorithm actually need to operate on a map table which holds<br>
>>> the pair <StringRef, Enum Type>. However, I will re-think about it and<br>
>>> modify it if it is possible in some way.<br>
>>><br>
>>> I will be committing first three patches as most of the review<br>
>>> comments are taken care for them. I will cross verify and make sure<br>
>>> that these patches will *strictly* adhere to CLANG/LLVM coding<br>
>>> standard before committing.<br>
>><br>
>> I'm really sorry, but that is *not* the policy of pre-commit review,<br>
>> or commit access after *approval*.<br>
>><br>
>> Please wait until you get explicit approval, especially for such very<br>
>> large feature additions to Clang. Reviewers often focus on one set of<br>
>> issues for a particular round of review and may have further issues<br>
>> they need you to address before committing.<br>
><br>
> I see you have already committed all three without waiting for<br>
> approval. Please don't abuse the commit privilege in this way.<br>
><br>
> The code still has some demonstrable problems by the way, which I<br>
> found with only a casual glance. I would assume that these would have<br>
> come up in subsequent review:<br>
><br>
> 1) The over-use of OwningPtr seems like a serious code smell. I would<br>
> want to understand why these are pointers at all here.<br>
> 2) There are copious "doxygen" formatted comments that don't use a<br>
> doxygen comment prefix of '///', instead using the normal '//'.<br>
> 3) The test cases seem quite haphazard; these are often the last<br>
> things to be addressed in code review, but possibly I'm just skimming<br>
> the patch in too little detail and much of the testing will come<br>
> later.<br>
> 4) There is no -fno-openmp to complement -fopenmp. Having this ability<br>
> to turn off features by appending flags is something we strive for in<br>
> the driver.<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
mahesha<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br>