user types

[Avi Bryant]

On Sat, 5 Mar 2005 16:59:46 -0400, Lex Spoon <lex at 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