Dave,

I think we've found basic consensus on this issue...

Small commits do generate more noise,


No they don't.  Size is unrelated to content / noise.

but I find that it is
> easier to read, assess, and manage the changes if the commits
> are small. I have spent a good deal of time doing this for
> http://www.squeaksource.com/TrunkUpdateStreamV3 and my perspective
> is based largely on that experience.


> If I were to point to something in need of improvement, I would say
> that is the performance of our Monticello tools.
>
> I *love* having the MC change management directly in the image where
> everything is directly accessible, browseable, and minimally dependent
> on external tools. But I have to admit that the tools are slow.
> Processing the update stream is slow, comparing versions is slow,
> and reading packages is slow.


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.

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.

And I strongly suspect that if all of
> these things were instantaniously fast, then none of us would care
> about how big or small the commits were.
>

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.

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.

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.


>
> I may be wrong, but I have to suspect that some profiling of common
> use cases, such as updating Squeak from the server, might identify
> some huge opportunities for improvement.
>

There's a bug with the "Move to Treated" that I think is an easy fix.  I
would love if you would update squeaksource.com to the latest code and use
that experience to find/fix any bugs that we can then backport to
source.squeak.org...


> But even if those improvements never happen, I think that small
> commits are a good thing.
>

Well, I do hope you don't think splitting a single piece of functionality
across multiple small commits is a good thing.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191121/8a65aa67/attachment.html>