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
packages@lists.squeakfoundation.org