iSqueak

[Avi Bryant]

On 6/18/05, Doug Way <dway at mailcan.com> wrote:
> 
> Ok, so a group of release people would have commit rights to the (3.9)
> release repository.  I wonder if we might also want the package owners
> to have commit rights to their packages in the release repository as
> well.  (Although I guess commit rights are repository-specific, not
> package-specific?)  Because the release repository may end up being the
> location of the de facto "latest/bleeding-edge" version of the package,
> whereas the "master" repository for the package is more for stable
> versions.

We can make commit rights as specific as we want, by hacking on the
repository code (I assume we'll start with SqueakSource as a base). 
But I would probably incline towards either giving someone full access
to the release repo or not.  If they're working on something pretty
core to Squeak, they should probably be allowed to use their judgement
about committing versions of packages they don't technically maintain
(like a modification to Kernel requiring some change to Collections or
something).  If they're working on something more external, they
should just commit to their own repository and have some release
manager copy specific versions into the release repo.  I think that's
more or less what you say later in your message anyway, just trying to
get my own thoughts clear.
 
> So, a typical scenario would be that a package, say Network, goes
> through a number of new versions in the release repository during 3.9
> development, from Network.3 to Network.17 or something.
> 
> So anyway, 3.9 final contains Network.17.  The Network package owner
> may decide to not let any of the interim versions into the master
> repository for Network, and only add the final Network.17 version.  Or
> he/she may decide that Network.12 is stable enough to be generally
> useful, and include that one in the master repository as well.  But it
> might be easiest for the package owner to add new enhancements into the
> one in the release repository, so there's no merging to worry about
> later.

I'm not really sure what you mean by "no merging to worry about
later".  It's perfectly possible, for example, to maintain multiple
branches in multiple repositories and be constantly merging between
them.  Or to have the same versions mirrored across multiple
repositories.  Or to have some versions in a particular branch in one
repository, and some in another, etc.  It's probably best in this
context to think of repositories more like tags: putting something in
the release repository means you're tagging it as "releasable".  But
it might have been a version that you originally committed to an
internal development repository and copied over.  Monticello is much
more flexible than CVS for that kind of thing because each version
carries with it all the ancestry metadata it needs, and a repository
is just a collection of individual versions + access rights.  Does
that clarify things somewhat?

> As far as SqueakMap goes, I'd imagine that the final/stable versions in
> the master repositories would typically all be available on SqueakMap
> for people to use, but we probably wouldn't bother with making all of
> the interim/alpha release repository versions (e.g. Network.4,
> Network.5, etc) available on SqueakMap.

Yeah.

> Are we ready to go ahead with this? :-)

Well, let's get a repository set up and see how it goes.  What's the
current status of the modules.sqf.org server?  Does it have the
capacity for an instance of SqueakSource for this, or should we find
somewhere else to host it for now?  Bert, I know you guys have made
some mods to SqueakSource as well, would it be easy enough for us to
make a fresh copy of your setup and deploy that?

Avi