Bert Freudenberg writes:
I'd go for one MC package per plugin. If I were to start toying with a new plugin I'd put it into a separate package. In fact, that's what I did a couple of times. When the plugin gets ready for inclusion in the official repository, nothing would have to change, history is preserved etc.
I'd go for a total of one MC package for everything just as we have now. It makes it easier to load, to share, to branch, and to keep in sync. With a single package it's impossible to end up with versioning problems between sub-packages. I know that there are MCC thingies that should help when loading from a Monticello repository, but how easy are they to bundle for SqueakMap or merge, or fork in a private repository?
To increase decentralization, why not just give Andreas and Rob write access to a central publically readable repository? If Rob only needs access for Crypto, then let's just trust him not to abuse commit privileges. If commit privileges are abused then they can be removed and all changes will be under version control so should be able to be undone. Giving out write privileges would also allow people other than Tim to commit (harvest) obvious fixes. Tim can always be required to inspect any release then bless it before writing the commit message.
The biggest problem people strike when starting to help out on Exupery is assembling a VM build environment. Splitting VMMaker into separate projects will make this harder as Exupery has it's own VMMaker branch. With a single MC package this is easy to deal with. A single package makes it easier for people to maintain experimental branches outside of the mainstream VM.
VMMaker is still small enough to email comfortably. The only good reasons I can see to split it is if people want to mix and match versions of new packages or not install the entire thing. Neither seems probable especially as plugins can already be built separately.
Bryce