<div dir="ltr"><div dir="ltr">Dave,</div><div><br></div><div>I think we've found basic consensus on this issue...<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Small commits do generate more noise, </blockquote><div><br></div><div>No they don't.  Size is unrelated to content / noise.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">but I find that it is<br>
easier to read, assess, and manage the changes if the commits<br>
are small. I have spent a good deal of time doing this for<br>
<a href="http://www.squeaksource.com/TrunkUpdateStreamV3" rel="noreferrer" target="_blank">http://www.squeaksource.com/TrunkUpdateStreamV3</a> and my perspective<br>
is based largely on that experience. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If I were to point to something in need of improvement, I would say<br>
that is the performance of our Monticello tools.<br>
<br>
I *love* having the MC change management directly in the image where<br>
everything is directly accessible, browseable, and minimally dependent<br>
on external tools. But I have to admit that the tools are slow.<br>
Processing the update stream is slow, comparing versions is slow,<br>
and reading packages is slow. </blockquote><div><br></div><div>It's a database, Dave, it responds to the laws of software physics.  Any database, including a strictly file-based one like we're using (not Magma), will perform more slowly as you put more objects into it.  It's unavoidable and why, as it grows, you want the highest percentage of objects in it to be meaningful.  Whether a large revert, or a small one-line comment fix, inconsequential objects become the noises that dilute the value of any database.</div><div><br></div><div>But all that is subordinate to the fact that the MC ancestry is _the_ artifact we make and put out and resides on all of our computers.  This makes it something to not carelessly ignore like the typical black-hole log file.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And I strongly suspect that if all of<br>
these things were instantaniously fast, then none of us would care<br>
about how big or small the commits were. <br></blockquote><div><br></div><div>No, that's exactly backwards!  The truth is that _even if_ it were instantaniously fast, we all should still care about the quality of the ancestry.</div><div><br></div><div>Like I said, I think the recent commits have suggested consensus, no complaints here.  Maybe a bit small'ish for my taste, but Marcel is keeping the packaging (version description) comparably terse too.  It adds up to clear and meaningful unit-of-change.</div><div><br></div><div>There's always going to be _some_ noise, but we seem to be doing better.  With new people, it can be a good time to remember.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I may be wrong, but I have to suspect that some profiling of common<br>
use cases, such as updating Squeak from the server, might identify<br>
some huge opportunities for improvement.<br></blockquote><div><br></div><div>There's a bug with the "Move to Treated" that I think is an easy fix.  I would love if you would update <a href="http://squeaksource.com" target="_blank">squeaksource.com</a> to the latest code and use that experience to find/fix any bugs that we can then backport to source.squeak.org...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But even if those improvements never happen, I think that small<br>
commits are a good thing.<br></blockquote><div><br></div><div>Well, I do hope you don't think splitting a single piece of functionality across multiple small commits is a good thing.</div><div><br></div><div> - Chris</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>