<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Jerome,<br>
<br>
I am all in favour of your suggested improvements to MC, and have been
working on a few myself. Actually I have now refactored some of MC so
much there is no going back!<br>
<br>
Ideas include:<br>
<br>
An MC equivalent of a changeset, so that changesets can be managed,
browsed and now loaded (order-doesnt-matter) with the same tools as
normal monticello files.<br>
<br>
<blockquote>I think this would be particularly useful for back porting,
develop in the latest squeak, and have a managed patch for '3.7 can
load 3.8 packages compatability patch.mccs'. This patch can then be
loaded "prior" to any packages which may use it. It may patch squeak or
the package, either way.<br>
<br>
</blockquote>
Now Monticello (1.5 ;-) can theoretically do things like, load a
class, in the middle of a class hierarchy, rather than only as a leaf
class (If I can debug it) the mechanism is in place. It can also
add/remove instance vars (etc) to other classes as well as extending
them. I haven't had time to test these out yet.<br>
<br>
What I dont agree with you is on your incremental process.<br>
<br>
The incremental process guarantees that everyone who wants to
contribute is working on a moving target. This leaves one person in the
driving seat to guide the continuous integration, and that is why there
is so much pressure involved.<br>
<br>
My suggestions would be to plan a number of items and see them all
worked on together. Integrating all of the tasks simultaneously and
regularly. This is effectively what I have done on 3.9.1<br>
<br>
I will attempt a diagram!<br>
<br>
Your process:<br>
<br>
<tt>Squeak + MCUpdate1 + SMUpdate2 + KernelFix (breaking MC1 and MC2) +
MCUpdate1b + SMUpdate2b.<br>
</tt><br>
My Process.<br>
<tt> <br>
</tt><tt>(fixed point) + MC Latest</tt><br>
<tt>Squeak-stable -> + SM Latest -> Squeak-unstable
(test, fix and iterate)<br>
+ KernelFixLatest<br>
</tt><br>
<br>
<br>
The aim is a list of tasks to be completed, and have a script that
loads all of the results of the tasks in. <br>
<br>
For example: 3.11<br>
<br>
"Project to harvest bug fixes"<br>
"Project to make all UI elements Scriptable" via Scripter<br>
"Project to make a nice UI display for interrupting a progress bar
in progress"<br>
"Project to implement proper logging facility"<br>
"Project to migrate the kernel to use the logging facility"<br>
"Project to mark up packages, to generate minimal functional
versions automatically".<br>
"Project to develop further tests for the base image"<br>
"Project to integrate flow for the primary stream support"<br>
"Project to replace FileDirectory"<br>
"Project to get and keep old packages loadable"<br>
add Compiler, Tools, Morphic3, etc etc etc<br>
<br>
All of these could be worked on simultaneously and continually
integrated in a script to generate an 'unstable' release.<br>
<br>
This was not viable before, because such a build script would
constantly run into problems. For example, rather than tweak the
TTFFont Speedup fix to make it loadable, I spent a couple of days
fixing the loader so the problem should not reoccur. Removing loading
order dependencies should also make this simultaneous-integration
approach one step closer to reality.<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">Several comments
1) time
It takes a minute or two to download an image zip file
on a high speed broadband.
Compared to that 20-30 minutes for updating seems
unacceptably long.
</pre>
</blockquote>
So one machine automatically runs the build integration script, and
everyone else can download it.<br>
<br>
Individual developers can have their own -unstable branches so as not
to break other peoples work in progress.<br>
<br>
I demonstrated this 4 months ago, and Installer supports the ability to
have stable/unstable/personal versions of each script, via its search
'path' parameter. <br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">2) MC will have more problems on large chunks than on
small. And it will take a good long time to report the
problems. The crash-fix-tryAgain-crash cycle is too
long IMHO.
</pre>
</blockquote>
MC only installs the changes, I guess it is the download and anaylsis
that takes much of the time.<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">3) With 1 and 2 being true the tendency to burn out
the helpful image updater will be great.
</pre>
</blockquote>
Lets automate the image updater, and the rest of us can work on Squeak.<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">
The problem with 7109 happened in a different way
earlier (First try never got into the image.)
So this is the second attempt.
</pre>
</blockquote>
Thats the problem with a moving target, multiple platforms etc.<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">This multiple attempt is typical of worthy problems.
At the end of 3.9 finding a way to insure changeset
current was not nil took more that half a dozen tries.
Each yeilding a small amount of information that got
us closer to the solution.
My impression is that Stef did a lot of work to get
though each cycle because MC is heavy and slow
</pre>
</blockquote>
Again I advocate using MC, but not for small incremental changes. <br>
<br>
Suggest to use it as a publishing Source code control mechanism.<br>
<br>
On every iteration, save all packages that have changed.<br>
<br>
To final gm-release, load from repositories. <br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">a) Somehow it seems to me that not only should
changeset be able to automatically become MC package
updates. It should work the other way also. You
should be able to specify a specific diff and have mc
create a change set that would recreate that
difference.
</pre>
</blockquote>
I have made MCDictionaryRepositories available , and 'System Changes
Sets' is an in memory virtual Monticello package.<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">Those MCdiff equivalent change sets should then be
able to be archived. and downloaded locally and
installed or filed into an image. This at least
creates a ratchet process of small steps. Saving time
</pre>
</blockquote>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">overall for test pilots. Producing and equivalent
result to what we are attempting to do now.
b) You might need to have two co-located people
sharing the image creating task so they can spell each
other. And increase the possiblity of avoiding either
of them burning out. Colocation is to insure a wide
stream of communication between the two of them.
Finding this kind of resource would be maybe
difficult. But it wouldn't hurt to ask.
c) IMHO it needs to be admitted that the current
choice for maintaining an image is not a good final
choice. Some real deep though needs to be given to
</pre>
</blockquote>
It is a good choice for partitioning an image, and source controlling
those partitions.<br>
<br>
It is just not a good choice for the little tweaks and fixes, or the
broad across the board fixes that a release team needs to do.<br>
<br>
My plan allows both. By allowing a Package to have a subset, being a
minimal functional version, more and more stuff can be unloaded from
the base image, and managed in packages. The remainder can be looked
after any which way you like as long as the image can be saved to the
repository(s) and loaded back in again successfully.<br>
<br>
<blockquote cite="mid:994924.97536.qm@web50310.mail.re2.yahoo.com"
type="cite">
<pre wrap="">I am pretty sure I have left out good and obvious
ideas. Its important to communicate what I have
observed and thought of so far. Can you add something
that might help?
</pre>
</blockquote>
I think that the majority of the problems that previous teams had can
be resolved by improving the tools.<br>
<br>
best regards<br>
<br>
Keith<br>
<br>
p.s. I did get your email<br>
</body>
</html>