[squeak-dev] Re: The Trunk: System-cmm.913.mcz

Chris Muller asqueaker at gmail.com
Thu Sep 1 19:42:29 UTC 2016


Hi Marcel,

> - Please refrain from committing unrelated changes that are easily to
> separate. If you have troubles uploading the 1000K MCZ for the System

I do keep significant changes, which are unrelated to each other, to
separate commits, however, I prefer to piggy-back my meaningless
changes like color tweaks or comment typo's.  The reason is, when I
arrow through the MC history of a package, I only want to see
*meaningful* changes, not dozens of meaningless tiny little fixes and
roll-backs that don't need to be consumed later, therefore, don't need
to be in their own commit.

This isn't even about the heavyweightness and unscalability of MC,
which is an issue in itself, but purely about having a dense and tidy
MC history domain.

MC is able to handle all the diffing, merging, backporting, etc. in
spite of this.  You didn't explain why you prefer to have thousands of
micro versions...

> - That "patch.st" hack seems like an indication that there are several
> situations where you cannot cope with the .image characteristics of the
> Smalltalk system. Please think about a better solution because the .image
> file should usually not be read-only. It impedes Smalltalk-style maintenance
> of such an image. While there have been good reasons in the past for
> treating the .image in the Etoys bundles as read-only and relying on project
> import/explort, I do not agree that we should make such a specific case
> common practice. This "patch.st" feels like a first step towards yet another
> CI/build system, which we already have with smalltalkCI and TravisCI.

I don't know how to respond to these comments other than -- yesterday
when you spoke of avoiding the image from growing into a "beast" -- I
totally agree and that's why, IMO, all Squeak-based servers should use
this design, because that's what it does.

> - This commit message would benefit from a little more explanation. There is
> plenty "what you did" but too little "why you did it". For example, the
> words "... to be re-patched in the event of a restart" really need an
> explanation of why you cannot just supply a start-up script to do that
> patching like "./vm some.image patch.st". Please invest more time in more
> elaborate commit messages.

I think the issue is that I should write some documentation about
making a Squeak server using this design.  That's where the answer to
such question would be found..  MC commits only should have enough
information to understand the context of the *change*, i.e., "what's
different", not any broader explanations of how the system works.

BTW, the answer(s) to that question are:  1) because nearly every
single script requires its own ".st" counterpart already, 2)
daemontools runs the #run script, not #patch, and 3) I require to be
able to ascertain exactly what I'm running in production from the
command-line, without having RFB' into the image and start diffing the
dirty MC packages in the production server...

Best,
  Chris


More information about the Squeak-dev mailing list