On 6/18/05, Doug Way dway@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