iSqueak

[Doug Way]

On Jun 11, 2005, at 7:16 PM, Andreas Raab wrote:

> Actually, instead of having "approval flags" I'd recommend having 
> "release repositories". E.g., consider that we're setting up a 3.9 
> repository which defines the "latest" package versions for everything 
> that ought to be in 3.9.
>
> Rather than "approving" a package version in their own repository, a 
> maintainer (or release master) would publish (or copy) package 
> versions to the release repository. This has a number of extra 
> advantages - fixes that turn out to be important for a release can be 
> put into this repository but may never appear in the "master" 
> repository for the package (because it might have been a last-minute 
> workaround). Integration fixes can be done for the release and then 
> fed back to the package owners.
>
> Basically, you're defining your own package environment, treating the 
> repository as a distribution and decide when you want to update the 
> distribution from the latest package versions developed by the owner 
> of the package.

I think this sounds good.  It almost seems like the only way to do it, 
actually.  (For now, at least.)

The other thing I like about this is that it handles the case in which 
you're making a big change in a release which needs to cut across 
several packages.  All the packages are in the same repository, and 
they can be updated at the same time.  It's more cumbersome if they're 
spread across different repositories, especially if the person making 
the change only has access to some of the repositories.

Certainly if you're doing package-detangling work, you'll need to make 
changes to multiple packages at once.

>> The initial maintainership model could err on the side of openness,
>> maybe even having some people with write access to all packages.  Then
>> we could restrict it a bit more later.
>
> With the above model you could restrict commit rights for the release 
> repository to the people actually working on the release, whereas 
> access to the "master" repository is limited to whatever the package 
> owner decides. This seems like a good model to me because it leaves 
> the responsibilities in the right places.

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.

Well, I guess it's up to the package owner whether they want to do 
major new development in their own master repository, but then they'd 
have to worry about merging with the release repository version later.  
In some cases that might make sense.  I guess it depends on the 
package... with something like Kernel, probably all development would 
happen in the release repository.  With something more external like 
SqueakMap, most development might happen in the owner's master 
repository, with the latest version being copied over to the release 
repository occasionally.

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.  (My Monticello 
ignorance is showing here... I assume that every commit to the package 
results in a bumped version number?  Looks like I will be getting more 
familiar with MC soon!)

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.

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.

Just some thoughts.

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

- Doug