2016-09-01 21:42 GMT+02:00 Chris Muller <asqueaker at gmail.com>:

> 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...
>
> Hi Chris,
the main reasons for using atomic commits:
The ability to review things - large blob of unrelated things are difficult
to review
The ability to know which changes go together if we want to backport/revert
a patch/feature
 and eventually to cherry pick changes from one branch to another branch
 (more a git feature than mc, but could be done in mc too).

Separation of concerns: putting different features into different commits
is just like housekeeping,
like classifying classes in right categories and methods in right
protocols...
This is not strictly necessary but help following the stream of changes.

At extreme level where branching is easy like git, one well accepted policy
is to put each feature into a different branch.
In mc, where each parallel commit is in its own branch (no matter the
naming conventions),
this is somehow what we do (or at least should do) when committing in inbox.
This does ease the work of integrating those changes.

Why should the policy be different in trunk?



> > - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160901/a89b6c61/attachment.htm