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
Yes, there potentially a difference between development repositories and release repositories. Development repositories get updated much more frequently, and have a lower standard for what is allowed to go in.
This said, it may well be easy to use the same technology for both. At the least, the same image seems likely to want to pull from both releases and local developments, and so it is important to allow them to be used in the same image.
Additionally, there is likely to be a notion of internal development versus real releases. This is something different from Debian, where almost all software has an outside development infrastructure. Again, though, it may be easy to use the same technology for both. Making a "release" could simply be a matter of pushing a copy of the package entry out from a local repository to one that is used more widely--much like people can pick particular MCZ files on SqueakSource to publish to SqueakMap.
As far as I know, Avi's characterization of local projects is correct. To mention two specific examples:
1. I don't think Scratch is using any of the public servers right now. They have thrown up their hands and are basing their work on some 2.x image.
2. The Georgia Tech group has some software maintained locally. I guess they could post it publically, and sometimes I toy with the idea of doing so. It seems really strange, though, to post code on SqueakSource or SqueakMap which has hard-coded pointers to our internal servers, even though this code is not really secret.
The GT group has 6-7 "developers" per semester (though the development is extemely light), with a quickly revolving set of people. I don't know how many people work on Scratch, but I'd guess that it's about the size Avi is talking about.
I don't know of anyone actually using Squeak for something that is really, truly secret. We might imagine, though, that people might one day build commercial services in Squeak. So while it is nice to support truly private servers, it may not be a pressing need right now. (Though it's hard to say; it may be a good question for squeak-dev -- tell us your secret commercial program you are hatching. :))
Oh, one final note. www.apt-get.org lists many hundreds of separate apt repositories for Debian. It seems that if this feature is available, then people will use it heavily, for whatever various reasons.
-Lex
Am 09.03.2005 um 14:43 schrieb Lex Spoon:
I don't know of anyone actually using Squeak for something that is really, truly secret.
If you would know, it wouldn't be truly secret, would it? ;-)
We might imagine, though, that people might one day build commercial services in Squeak.
We (impara) are precisely doing that, right now.
So while it is nice to support truly private servers, it may not be a pressing need right now.
We currently use non-public MC repositories, so our immediate need is satisfied. But of course we're interested in everything that evolves :)
Btw, the number of people working on any particular project/package is as others have reported, less than a dozen.
- Bert -
On Wed, 9 Mar 2005 09:43:41 -0400, Lex Spoon lex@cc.gatech.edu wrote:
I don't know of anyone actually using Squeak for something that is really, truly secret. We might imagine, though, that people might one day build commercial services in Squeak.
We might indeed.
I'm involved in three commercial Squeak/Seaside projects right now, at varying levels of secrecy. One is funded by the University of British Columbia, and so is quite open: it's a web application that lets researchers enter and manage their CV information in a structured form (or import it from course registration databases and journal indices), and then automates the process of generating grant applications and the like. I count it as a commercial project because although it was developed for internal use, there's been a lot of interest in licensing it from other insitutions.
The second, which is more secret, is a piece of internal infrastructure for a financial institution.
Avi
packages@lists.squeakfoundation.org