Hi folks!

As we all know we are in the middle of a heated discussion about our 
release process etc. I haven't read all messages nor do I think that any 
of the two "sides" (Andreas and Keith basically) are 100% wrong nor 100% 
right.

Anyway, disregarding all that :) - I would like to do a sketch on an 
"ideal" daily process for development. I would appreciate this thread to 
NOT turn into the current "war" between "Trunk" and "Bob", ok?

MC is a very good tool and Keith/Matthew and others have turned it into 
an even better tool AFAIK using SystemEditor as a base etc. It does have 
its limitations though:

1. It tends to be more coarse granular than other tools. "commits" tend 
to be more seldom, at least when I work in it. Probably due to less 
stellar performance, might have been fixed.

2. It needs history to do its merge magic. Thus it doesn't play well 
between forks. It plays very well within a package or within a group of 
packages (a fork perhaps).

3. It is centered around packages defined by PackageInfo which more or 
less means "a group of class categories + class extensions". It does 
have MC configs now, and I haven't used them myself yet so I can't 
really comment.

The above three bits are different with Deltas.

Anyway, I am trying to envision how an MC based approach like "trunk" 
could work together with Deltastreams. DS is meant to replace Changesets 
and could complement MC in the above three departments (and more).

For example, we could create some kind of "commit tool" that operates 
above MC/DS which would use Delta recording (exactly like Changesets 
record today) to catch current image modifications and to offer a nice 
UI to select a subset of those modifications (or all), enter commit 
comment, classify it and push "commit".

This commit tool could have some checkboxes and drop down menus to 
classify this commit and also tell where to "send it":

- Also snapshot MC packages. This would cause an MC commit as well as a 
Delta to be produced. If not checked we only produce a Delta.

- Bug fix to send to proper streams based on touched PIs. The tool could 
then select proper Delta *stream* in which to publish the Delta based on 
what PIs it touches.

What would this achieve? Well, first of all we might be able to work 
more completely in Squeak. :) We would above all be able to get "cross 
fork pollination" using the Deltas that are being published alongside 
the MC snapshots. Pharo could be "listening" to our bug fix stream for 
example. And vice versa if Pharo decides to use this. And well, it opens 
up lots of other possibilities I think.

Anyway, would be interested in all feedback on this idea.

regards, Göran