V3dot10 process and meta-problems

(directed to v3dot10 list and cc'ed to squeak-dev)

Hi Edgar and Ralph,

Case study:

I started with Squeak-7105
world-menu>help>load updates from server.

It ground thru changes for 10-20 minutes.

Finally about 30 minutes later (while loading 7109)
and a long time after starting on 7109 it comes to a
halt saying:

"Error: Could not find version 'EToys-edc.23'. Maybe
you need to add a repository?"

-----

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. 

So basically for distribution one person updating an
image and 20-100 people downloading it is better than
20-100 updating from a repository.

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.

3) With 1 and 2 being true the tendency to burn out
the helpful image updater will be great.

The problem with 7109 happened in a different way
earlier (First try never got into the image.)
So this is the second attempt. 

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
compared to changesets and update streams. This tends
to burn out the limited and least replaceable
resource, the self-funded time of the release team
member in charge of making things happen.



Solution finding.

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.

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
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
this by all those who care for the future of
squeak-dev squeak.

More

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?

Yours in curiosity and service, --Jerome Peace











       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/