[Scummvm-devel] The Situation (omnious music..)

[James 'Ender' Brown]

*long snip*

> Maybe it is indeed time to fan out into multiple projects... One which 
> deals with the OSystem stuff (and the rest of the infrastructure, so: 
> backends/, common/, graphics/, gui/, sound/). And then ScummVM 
> (=AdventureVM... ), and residual, and awe, and anything else which 
> might want to make use of it... of course that would decouple 
> development of the backends from the frontend, meaning slightly less 
> flexibility... OTOH, having "stable" release of the backend stuff to 
> work against might indeed have its very own advantages... projects 
> would use "OSystem 1.0.4" or "OSystem 1.2.1" etc..

I really don't see it as necessary. There is nothing at all to force
people to work or support a ScummVM engine they don't want to. If you
look at our README it's pretty obvious we have a group of people working
on OSystem+Backends, as well as various engine groups.

I did suggest some time ago, mostly due to bloat, about seperating
OSystem/launcher and engine modules in CVS. But thats simply a
logistical matter. It -would- allow making engine releases independant
of the other engines and the ScummVM core, but it also makes builders
jobs more tiresome.

But again, what's the difference in splitting into multiple projects?
'ScummVM' is simply a subproject of the 'ScummVM Project', as are
Residual and ScummEx. ScummVM itself has various engines, which could be
considered sub-sub-projects.

How does it affect developer A if developer B adds a new engine that A
doesn't like? Not in the slightest (unless A is a porter, or engine C
requires OSystem changes and A is a backend dev... but dealing with new
stuff goes with those jobs anyway!)

That's my opinion on splitting things up, anyway :)

 - Ender