<div class="gmail_quote">On Mon, Jun 11, 2012 at 5:19 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 11, 2012, at 4:02 PM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Mon, Jun 11, 2012 at 3:53 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Author: kledzik<br>
Date: Mon Jun 11 17:53:15 2012<br>
New Revision: 158336<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=158336&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=158336&view=rev</a><br>
Log:<br>
Move implementation of WriterOptionsMachO to its own file. Reduced redundant<br>
ivars in WriterOptionsMachO instead have its methods compute ivar interactions.<br>
Refactor mach-o Reference Kinds and introduce abstract class KindHandler.<br>
Split up StubAtoms.hpp by architecture.  Add support for 32-bit x86 stubs.<br></blockquote><div><br></div><div>This really feels like it should be split across separate commits to make code review more tractable Nick...</div>

<div><br></div><div>You have several changes which are no-functionality changed, just moving code around. Those should always be separate. They can be reviewed super easily, and that allows the commits which actually make changes to be reviewed with a precise diff.</div>

<div><br></div><div>You actually have the different steps in your log message: each sentence feels like it should have been its own distinct commit.</div><div><br></div><div><br></div><div>For reference, I mention this because several people have come to me expressing interest in getting involved with lld, but have struggled to review the existing code and start reviewing commits because the commits were very lumped together.</div>
</div></blockquote><div><br></div></div><div>I understand simple, modular commits for a mature, large code base with lots of developers involved.</div><div><br></div><div>But, lld is still very much in its infancy.  These commits are more like check-points.   I expect plenty more refactoring churn before lld is stable enough to open it up to more contributors. </div>
</div></div></blockquote><div><br></div><div>I think that you're creating a chicken/egg situation. I think that you have to act as-if there are other contributors in order to gain them. If you simply checkpoint work and convenient points, that will disincentivize anyone from getting involved because they have no idea what's going on.</div>
<div><br></div><div>I think it's important to get more people involved *during* the infancy of the project rather than afterward. That's the whole point of doing open development as part of a community. =/</div><div>
<br></div><div>Note that you already have open projects, at least one other contributor, and the *implication* that other developers are wanted. Is that genuine or not? Comments like "open it up to more contributors" raise concerns about the community approach here.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>That said, if there are developers interested in lld, I'd very much like to hear what design areas they would like documented better.</div>
</div></div></blockquote><div><br></div><div>But it's not just design areas they're interested in. They want to hack on code, and to do that they need to understand the *code*, above and beyond any design concerns. An essential part of that is doing code reviews and watching the progress so that they understand how development is progressing, where things are going, and how to jump in and get involved.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Questions like: How would X be handled by an in-memory based linker?  or How does the Atom model handle a cpu with feature X, etc.   Getting me to document  those design points will help everyone come up to speed and see how their needs fit into the lld model, and ensure lld can support (eventually) everyone's linking needs.</div>
</div></div></blockquote><div><br></div><div>Yes, absolutely. But these aren't mutually exclusive, they are complementary. =]</div></div>