On Wed, Nov 23, 2011 at 08:42:43AM -0300, Esteban Lorenzano wrote:
I think we need to start deconstruct the "huge beast" it is VMMaker right now, and that means at first instance split the package in smaller parts. No reason to have all plugins (newer, older, living, obsolete) in just one package. But also, it would be good (IMHO) to have all plugin packages grouped in just one repository (same VMMaker repository) and easily installable with a ConfigurationOf... (now we have metacello, no reason to use hand made scripts)
If all agree in this, I can work a little on the split process (not right now, but in this weeks :) ).
Hi Esteban,
I agree in principle, but please do not do it now. I think it is very important to continue merging the two main VMMaker branches (traditional and oscog). I have been trying to make progress with this, and Eliot is certainly supportive, but I have to say that it is a lot of work and we rely heavily on the Monticello tools and matching package structures when comparing and merging code between oscog and trunk. If we were to break the packages into smaller pieces with different versions for trunk and oscog, the result would be difficult to keep track of in the VMMaker repository.
If we want to achieve a more modular VMMaker, the most important thing to work on is reconciling the code bases, both in VMMaker and in the platforms support. There is a lot of work to be done here, and I don't know if anyone is even looking at the problem on the platforms code side (aside from Andreas, who did some significant updates to the win32 and Cross files in trunk). Once that work is done, we can reorganize package structures to improve the overall maintainability. But in the near term, changing the package structure in VMMaker would make the job more difficult for me.
Thanks!
Dave
p.s. I know from personal experience that breaking packages into smaller pieces is not always a good idea, even if it sounds like the right thing to do. I split both the CommandShell and OSProcess packages into smaller packages, which seemed like a good idea because it would make them more modular. For CommandShell, this was very helpful, and I'm glad I did it. But for OSProcess is was a big mistake, because it makes it harder for me to manage version releases, and it has provided no practical benefit to the users of OSProcess. So sometimes it is a good idea to do this, and sometimes it is not ;)