update stream policy

Avi Bryant avi at beta4.com
Sat Jan 17 19:47:25 UTC 2004


On Jan 17, 2004, at 11:23 AM, Diego Gomez Deck wrote:
> I propose to evaluate FIRST which resources we have before going with a
> list of goals/wishes.
>
> How many of us are active working? How many time we're spending on this
> work?

Diego, we agree that it's an issue of resources, but we disagree on 
what the solution is.

We don't have many people willing to wade through the BFAV.
We don't have many people willing to maintain the update stream.
We don't have many people willing to test every small image change 
against every other piece of code that's in the image.

 From my point of view, this is a strong argument to reduce the load on 
the reviewers, on the guides, and on the testers, by making the image 
smaller.

I realize that you're worried about bitrot - if the image isn't a 
monolithic whole, but is split into packages, those packages can get 
out of sync with the image or with each other.  This is true.

However, the only way to prevent bitrot in the current situation is 
that every time someone makes a change to one piece of the monolithic 
image, they have a responsibility to track down all the affected pieces 
of code and modify them too.  This is an exhausting and frustrating and 
error prone process, and it results in the slow progress that we see 
with the BFAV - making and reviewing changes to a system as large as 
the base Squeak image is *hard*.  Look at the hundreds of changes 
involved in the KCP or Babel work.  Kudos do those that did that great 
work, but as you point out, very few are willing to undertake something 
like that.

By splitting the image into packages, that responsibility gets 
delegated to the package maintainers.  When, say, Babel makes it into 
the base image, then every package maintainer that wants to stay up to 
date has a responsibility to make sure that their strings get 
translated.  Yes, some package maintainers might be irresponsible and 
will let their packages rot.  If it gets really bad, someone more 
responsible will take over.  But I guarantee you that by splitting up 
the responsibility in this way you will get more total work out of more 
people, because the divisions of labor will be clear.

I'm going to try not to spend any more time on this thread because I 
think, frankly, that most people agree with me, and I don't know what 
else I can do to convince those that don't.

Cheers,
Avi




More information about the Squeak-dev mailing list