<div dir="ltr"><div>Sean: I agree with many of your points, but I don't agree that we have to address them all beforehand. Some of them we don't even know just yet. But I have started up the documentation and will update that with as much information as I have.</div>
<div><br></div>Chandler: ping?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 8:15 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Some really high-level thoughs:<br>
<br>
  One thing that I think has been neglected in the development of our other tools is what the end-user experience looks like. I feel like a bit of high-level "this is what I want the user experience/workflow to feel like" iteration at this stage could really have a significant payoff down the road. (side note: I love how clang-format is so easy to use, but it really has it easy since it doesn't need to fully parse and build AST's; clang-tidy has it a lot harder)<br>

<br>
  By "user experience/workflow" I mean a holistic end-to-end use case for the tool (such as our own, i.e. dogfooding). Especially:<br>
<br>
  * which commands they run to actually do stuff with the tool (and I don't mean in isolation; I mean a sequence of commands starting with `git clone`/`svn co`)<br>
  * what an external user's code would look like (where in their repository would they store extra checks of their own? how does this tie in with their build system? how to deal with backwards compatibility?).<br>
<br>
  I think we should have a clear vision of how we are going to dogfood this before committing any code, because honestly, if we don't use this, how can we expect others to? A couple questions off the top of my head:<br>

<br>
  * How is this going to integrate with our build system?<br>
  * Are we going to have pre-commit hooks? or a bot that automatically replies to patches on the mailing list/phabricator with issues flagged by clang-tidy?<br>
  * Is this something that a handful of people run periodically in batches, or is this something that we expect all developers to run on their code before committing?<br>
  * What fraction of our checks are idiosyncratic, and how many are generic and usable by other projects?<br>
<br>
  For example, I think it makes sense for llvm-specific checks to live in the LLVM source tree (*not* clang-tools-extra); e.g. our idiosyncratic include ordering. Then we get to feel what this actually feels like for an external project. Of course, as many have said, it makes a lot of sense to have a bunch of generally useful non-idiosyncratic checks that others can readily call upon in a config file, but we really need to consider idiosyncratic checks (i.e. C++ code using these APIs that is maintained in an external source tree).<br>

<br>
  Maybe we should build a pretotype (if you aren't familiar with that word you can ignore this sentence)? We have excellent technical implementation ability, so TBH actually building the tool isn't the hard part: we really ought to make sure we are building "the right it" before "building it right".<br>

<br>
<a href="http://llvm-reviews.chandlerc.com/D884" target="_blank">http://llvm-reviews.chandlerc.com/D884</a><br>
</blockquote></div><br></div>