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
|