Avi Bryant <avi at beta4.com> wrote:
> 
> On Jul 11, 2004, at 10:08 PM, Doug Way wrote:
> 
> > I guess we should brainstorm a bit on how this might work before 
> > making a decision, of course.
> 
> More than that - I would hope we would try it out in parallel with the 
> update stream for a few sets of updates to see how well it works before 
> we even talk about making a decision.

Yes, let's:

1. Draft a plan. (we are doing it now and when this thread is over I can
put an article on SqP)

2. Make an experiment.

> >   Erm, would the "image" be a giant single package in Monticello?  Or 
> > at least the part of the basic image which is not already split into 
> > other packages... which would still be a pretty giant package at this 
> > point.
> 
> No, I think we'd want to carve it up much more than that - maybe one 
> package per major set of system categories (Kernel, Collections, 
> Morphic, etc).  Though some of those (Morphic esp) are pretty huge in 
> themselves, and should probably be split more.
> 
> When Andreas and I tried a very early proto-attempt at this (see the 
> Squeak project on SqueakSource), we used one package per category, 
> which was easy, but probably excessive.
> 
> One thing to point out is that there's no requirement that the packages 
> have clean dependency chains between them - Monticello actually deals 
> reasonably well with spaghetti code arbitrarily carved into different 
> packages.  I had a feeling that would be a necessary use case in this 
> world ;).

That is VERY important. Because we can't take the time to untangle
stuff.
The important thing is that all code is covered and belongs *somewhere*.

 > > And then how would the update stream fit into this, if at all.  It 
> > would appear that the core committers would not need an update stream, 
> > at least.  Maybe there would still be an update stream for the 
> > "public" alpha image somehow.
> 
> I think the vision Göran was articulating was to get rid of the update 
> stream altogether.  That's not something we could do all at once, of 
> course, but I think it's a reasonable goal.

Yes, but we need to make sure we don't "loose" something. For example,
today the ChangeSorters work as a live "Changelog". We might want
Monticello "commits" to produce changesets in the same fashion, or
provide a similar service some other way.

Another thing is "do its" - not sure if Monticello has support for such
stuff today.

Let's pretend we have solved these issues - since we IMHO should keep
BFAV for external contributions/fixes - then the harvesters could
actually "commit" approved FIXes instead of queueing them up for Doug.

Or if the queueing is of some value Doug could commit them in the proper
sequence.

> Avi

regards, Göran