update stream policy

Andreas Raab andreas.raab at gmx.de
Sun Jan 18 15:25:19 UTC 2004


Hi Goran,

Just two quick notes:
> I cringe when someone thinks that "putting everything
> back in the image" is the solution.

As far as I can tell, noone said nor meant this. It seems to me that this is
becoming the standard reply to any comments on the problems we have with
maintaining code in external packages.

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

You are correct. This is all the more reason to include packages in the
community processes, and make the harvesting, review, and update process
work with external packages as well as with in-image code.

Cheers,
  - Andreas

----- Original Message ----- 
From: <goran.krampe at bluefish.se>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, January 18, 2004 3:55 PM
Subject: Re: update stream policy


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