[Vm-dev] Re: VMMaker organzation

[bryce at kampjes.demon.co.uk]

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