"Internal" updates (was: RE: [Squeakfoundation]Possible extra text for Welcome window in 3.4)

goran.hultgren@bluefish.se squeakfoundation@lists.squeakfoundation.org
Wed, 8 Jan 2003 10:19:09 +0100

Tim Rowledge <tim@sumeru.stanford.edu> wrote:
> "Andreas Raab" <andreas.raab@gmx.de> appears to have written:
> > The point here is not about whether an "internal" update stream _can_ be
> > useful. The point is that in order to be useful it has to be _put_ to
> > use, e.g., someone has to actually run the stuff that's in it. If noone
> > does, then it's only getting into the way of both, testing and the
> > release process in general (e.g., "is this update included?").
> Exactly so. My problem is that I don't see anything in the internal
> stream and without an uptodate sqfixes page (or suitable substitute)
> it's hard to keep track of what to look into. I haven't been keeping
> every email that could possibly relate to changes; perhaps I should.
> I think we just need to get some organisation into place. Now that
> assorted holiday type distractions are over maybe we can do so?

Yes, agree with Andreas on his points. I am not sure what Tim means by
"...I don't see anything in the internal stream..." because I have seen
stuff in there before it went out, but whatever.

The REAL solution is of course to follow up on the proposed tool that
Doug and I and Luciano have been discussing - a sort of Harvesting tool
using some similar mechanisms as SM does but in a package centric way.

The idea is that harvesters have the ability to review/comment and move
fixes forward in a kindof "assembly line" fashion into different stages
and finally out into an update stream. This "assembly line" will be
viewable by all (and kept up to date similarly to SM) so there will be
no doubt where a FIX has gone and what status it has.

And further we have been thinking of:

1. Adding Monticello to the mix like a "workbench" so that a FIX can be
"lifted" temporarily off the assembly line onto the workbench (a
Monticello shared repo) so that multiple developers can work on it "at
the same time" banging it into shape and then when it looks good lift it
back onto the assembly line.

2. When FIXes have gotten good reviews etc and passed whatever
criteria/stages we want to have it moves into the final "release queue"
which batchwise is published onto the update stream(s). Note the "s"
here which signifies that this tool should be "package aware". Perhaps
by having multiple assembly lines, a line for every package that wants
it, and/or possibly multiple release queues (for different packages)

Anyway, that is the gist of it. The idea is to reuse the architecture of
SM for much of it (but this is a completely separate tool of course),
add a Morphic UI of course and then off we go.

IMHO anyone can start working on this - I am pressed for time but can
surely help out regarding the SM base. Doug is good on the UI side and
also has the knowledge about the "Harvesting needs". Luciano was very
interested to help out and has looked into the SM code.

Furthermore Doug has written this on the subject - he is the man in
charge (sorry for blabbering):


regards, Göran