Doug
what we should fix is what do we do with the changes that are in 3.9alpha stream. I also have some new changes/fixes on my disc ready to be added to the stream.
Stef
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? :-)
Yes we should try that.
Stef