update stream policy

ducasse ducasse at iam.unibe.ch
Sun Jan 18 15:27:03 UTC 2004

> Hi all!
> I admit that I have only read a little bitty bit of this thread but
> while I am uploading the new SM2 server-image using a 56kb modem I
> thought I could say something at least.
> IMHO this is all about tool support. I cringe when someone thinks that
> "putting everything back in the image" is the solution.
Who said that? What is clear is that we need good tool support if we
do not want to have more death amongst the packages in the future.
You know that and I'm eager to see SM2.

By the way the starting point was about having Tests (the active and 
always synchronised
documentation) close to the code they document in the image for the 
image. For the package
each maintainer has to care of the tests related to his stuff.

> To answer
> Andreas directly (no 1 below):
> 1. SM2 has support for multiple maintainers. It is being hopefully
> deployed today (unless I barf it). This means several people can
> maintain the SM2 registration info and that includes making releases.
> (though there may be a bug in there regarding the upload area - oh 
> well,
> another day)
> 2. BFAV will (according to the developers of it at least) be moving
> towards being "package aware". This means that hopefully reports and
> fixes will be "funneled" to the correct persons etc.
> 3. We are tying the PIs with the SM2 packages. What this means is that
> we can automate a lot more from inside the image. We can make the tools
> "smarter". An obvious example is "Take this fix I just made, split it 
> up
> appropriately and mail it to the primary maintainers of affected
> packages". Yes, with SM2 and when TFNR is ready (=the whole image is
> partitioned using PI) then this can actually be implemented, and much
> more.

Exact. This is what I described too.

> 4. Next step for me in SM2 is dependencies etc along the lines I have
> outlined before. This together with proper releases (which SM2 has now)
> means we can make new releases of core stuff and then have the 
> dependent
> packages be updated when time permits. Some people shout for Avi to add
> dependencies - and fine by me. Just try to keep in mind what you are
> after, so you don't mistakenly mix SM-dependencies with 
> MC-dependencies.
just that this is me. I'm curious to see how the result

> The idea that a single person can first change say class Socket and 
> then
> make all the needed updating in all the dependent packages *all by
> himself* is something we need to drop. Sure, it had the illusion of
> working before in the monolithic image, but today with over 350 
> packages
> on SM it just doesn't work. And note my use of the word "illusion"
> because even before there was code outside of the image that broke
> horribly but people didn't see that - only the package maintainer
> himself did.
> Ok, now I have to help making some dinner.
> I will not participate more in this discussion until SM2 is up and
> running. :) I am on IRC though.
> regards, Göran

More information about the Squeak-dev mailing list