Hi Göran -

It'd be easier to give feedback if you had something to try out ;-) 
Abstractly speaking this sounds all cool but we'll only know when we 
actually try it. One thing that's not quite clear in this picture is 
where the "canonical" source for patches would be and how it would be 
produced. In most of what you wrote you've concentrated more on the 
harvesting aspect (i.e., being able to cherry-pick contributions from 
elsewhere) but how does an actual development flow look like?

Cheers,
   - Andreas

Göran Krampe wrote:
> 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
> 
> 
>