David T. Lewis
lewis at mail.msen.com
Wed Nov 23 14:22:24 UTC 2011
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 :) ).
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
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 ;)
More information about the Vm-dev