On Sat, 5 Mar 2005 16:59:46 -0400, Lex Spoon lex@cc.gatech.edu wrote:
It means that version 1 may well not work the way it was expected, and thus that we need to be prepared to watch how the tools actually get used and adapt to what people want. Some features, painfully, might not turn out to be useful at all. We should be careful not to get so attached to our theories, that we refuse to recognize what the users are actually doing.
Hear, hear.
There should be a way to have local repositories, so that the Scratch group can make progress. One implication of this is that identifiers of all kinds are going to have conflicts between the local repositories and the well-known global repositories.
It looks like mixin repositories would be useful, in order to support HP Lab's internal packages.
Along these lines, it would be ideal if it is possible to manage a package manually, without reference to a repository. It should be possible for one Squeaker to send a newly created package file to the Squeaker sitting beside them on another computer, without invoking lots of infrastructure.
One distinction that I make that I'm not sure if you're making here is between development repositories and release repositories: between, for example, SqueakSource and SqueakMap. My needs in the role of the developer of a package are very different from my needs in the role of a user of a package.
The way we've been operating so far is to have one central release repository, and many scattered development repositories. This isn't because anyone's enforced that approach, it just seems to be what people do: there are lots of local installations of SqueakSource, but I don't know of any local installations of SqueakMap. This makes sense, though; I would imagine that inside something like HP Labs, or netstyle, or impara, people mostly want to access packages in the developer role - they may not themselves be a developer on the package, but they'll be familiar enough with it to want to be aware of the various branches, the bleeding edge versions, the commit logs, and so on, and they want to be able to make and commit changes if necessary. It's only when sharing packages between organizations that you want all of that messy development stuff to be hidden behind simple version numbers and release notes. Yes, this is an oversimplification - an organization or group of collaborating organizations might get big enough that one internal group really does just want to access the releases from another internal group's packages. But I'm not sure it's an oversimplification that's really become a pain point yet. Those inside big, Squeak-using organizations, speak up! (Which raises an interesting tangential question: what's the biggest team using Squeak? The projects I've worked on are all in the 2-5 developers range).
It would certainly make things simpler if we turned out not to need decentralized release repositories (and we already have a model for decentralized development repositories). But is it just that people are working around a hole in the toolspace?
What I'm certain that we do need, even if we have a centralized release repository, is a way to have different views of it, controlled by different groups. A project like Scratch may not need to make a release available behind its firewall, but they will want to control which released packages and package versions are visible (by default) to Scratch users.
Avi