V3dot10 process and meta-problems

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/ 

On 5/17/07, Jerome Peace <[hidden email]> wrote:
> V3dot10 process and meta-problems


> 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.

MC already supports this, and we are using it.  If you look at the
actual change sets we are loading, you will see that they use MC to
load *.mcd files instead of the usual @.mcz files.  These are
differencial MC files, and are much faster to load than the usual
ones.  Faster, but not fast.


> 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.

Yes, it has been a lot of work for Edgar.

> 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.

MC clearly has a LONG way to go before it is good enough for
maintaining the image.  If you think the update process is slow now,
you should have seen it before we started using differential package
files (.mcd instead of .mcz)  People are welcome to hack MC and try to
make it faster.  In the meantime, Edgar releases images as well as
updates, and for most people that the best way to get the latest
release.  I don't think he has made an image for 7105 yet.

-Ralph