El 15/08/2009, a las 10:10, Göran Krampe escribió:

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

I'm a little disconnected of the Squeak world, for this, I ask: But  
are DeltaStreams working, stable, and functional?

Cheers.

Giuseppe Luigi Punzi Ruiz
Blog: http://www.lordzealon.com
Twitter & Skype & GoogleTalk accounts: glpunzi