iSqueak

[Doug Way]

On Jun 18, 2005, at 10:37 PM, Andreas Raab wrote:
> ...
>> 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.
>
> I don't think so. In my understanding there should never be active 
> development inside the release repository (the one exception being 
> integration fixes) because the point of packages is to do development 
> in packages (== the package repository). And if there isn't a master 
> repository right now for -say- the Kernel package, well, then I guess 
> whoever wants to hack it better create one. This is one of the ways of 
> assigning active responsibility for certain areas of Squeak - I am 
> sure it would spawn an interesting (and useful) discussion if Joe 
> Random Squeaker would request to create the "master" repository for 
> the Kernel to hack it. We need this discussion and we need the people 
> to take on responsibility for these areas.

Ok, I misinterpreted that aspect of the proposal.  Currently, most of 
the packages in the Basic image (as partitioned by iSqueak) don't have 
a master repository yet... only a few such as Monticello and SqueakMap 
do.  But once they're set up, I agree that it makes sense to have the 
active (non-integration) development in the package's master 
repository, then.

And preferably all or at least most of the packages would have a master 
repository with some package-specific development taking place.  I can 
imagine there might be a few neglected packages at first which only 
have integration fixes going on, though... but yeah, if Joe Random 
squeaker appears to start doing work on the package, that may get 
things moving as far as determining maintainership, etc. :)

>> 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.
> [...]
>
> I wouldn't do it that way. I would start from the release plan saying 
> "we'd like to have some network support in the next release". Based on 
> this the release master goes to the package maintainer/owner and asks 
> "what is the latest stable release people ought to use for the next 
> Squeak release" - to which the package maintainer would answer 
> "probably Network-foo.bar.mcz" and the release master would copy this 
> version into the release directory.
>
> At this point people can start testing the package. If there are 
> issues, they can be addressed by the package owner (the preferred way) 
> so that the release master only needs to copy the fixed versions over 
> to the release repository. If the issues aren't addressed by the 
> package maintainer (or if they are integration issues that must be 
> addressed in the release) the fixes would be posted into the release 
> repository and (hopefully) be merged back into the package master 
> repository. (and if this doesn't work, then someone might well stand 
> up and fork off a new "master" repository for the package as it is in 
> the release right now).
>
> Notice that at any point the person in control for a release is the 
> release master, not the package owner/maintainer. It is the release 
> master who manages the packages included in a release and the package 
> owner/maintainer supports the release master by addressing any issues 
> that have come up in the master package repository.

Ok, that pretty much follows from your clarification above.  Sounds 
good.

>> ...
>> Are we ready to go ahead with this? :-)
>
> Depends on who "we" is ;-)

The Packages team, Coordinators, various "SqF" members, people who have 
access to the update stream, and other organizations du jour. ;-)

But seriously, the Packages team, at least. (which is really just 
whoever is following this list)  Of course, this will have a big impact 
on Squeak 3.9 development, harvesting, etc.

One other issue is working on recruiting/assigning maintainers & 
co-maintainers for all of the packages.  Goran has done some work on 
this in the past.  But I don't think we need to wait for that to 
proceed.  In fact, I think it may be easier to find maintainers once 
the package infrastructure is in place and people see that it is 
working.

- Doug