[Scummvm-devel] Bringing our Core Code to another Level?

Johannes Schickel lordhoto at gmail.com
Tue Aug 13 23:18:06 CEST 2013

On 08/13/2013 09:57 AM, Arnaud Boutonné wrote:
> If the plan is to tell to people "fork and do whatever you want, we 
> don't give a shit", then we could spare a lot of time and potential 
> regressions if we just keep what we currently have, as it's precisely 
> how we proceed currently. People are forking, implementing things, 
> which rot forever as we explicitly don't care.

I am not sure where I claimed we will say "fork and do whatever you 
want, we don't give a shit". But I think it might be worth to point out 
how the current situation is for anybody who wants to use our core code:

Right now they would create their own copy of the ScummVM repo. Then 
they have to strip out all the ScummVM specific bits, that is logos, 
engines, engine credits, README etc. Finally they will have to add 
substitutes for these bits with their own bits. This means they have all 
sorts of changes to files which are also in the ScummVM repo.
     Then consider the point where we make a change in the core and they 
want to benefit from it. They would try to do a merge from our 
upstream's master. This will result in them having a ton of possible 
conflicts in case some files have changed in master which they had to 
replace to make use of our core. Then they have to resolve all these 
changes everytime that happens.
     Alternatively, they can do what Residual seems to do which seems to 
be copy over all the changes by hand and worry about it with even more 
manual effort.

These are all very tiresome and pretty annoying bits. My suggestion was 
trying to have a core where people would not need to replace anything. 
Then if there's changes to our core code they can simply do a merge and 
only need to adapt their code if there's any API or smiliar changes. 
This way it should be much *easier* for them (yes, easier for 
outsiders!). The creation of forks of a core repo for starting a project 
is a *technical* bit. It is in no way connected to whether they want to 
be a ScummVM sub-project or not.

This is an *improvement* over the current situation. That is, instead of 
"we don't give a shit" I want to make life easier. Thus, I completely 
fail to see your point here. I started this discussion to make life 
*easier* for everybody and I'm get complained about for that. That is 
pretty hypocritical in my eyes.

> Even worst, at some point we may be tempted to ask developers to 
> choose their camp and leave one of the projects, after some dispute 
> between the two projects

I am not sure but I have the feeling you want to make people make this 
decision when they want to take advantage of our core code. That is 
either they join ScummVM or "you don't want to be one of us, so go away, 
but we hate you and don't want you to have an easy life". I'm really 
against such a policy.

My idea would have been to encourage people using our core by making 
things *easier* for *them*. This way we have people working with our 
core, which in turn might make them have great ideas of improvements for 
it or even making actual improvements. Thus, we open a new door to gain 
developers who help us improve our code. These developers might not have 
a background of being interested in ScummVM itself. If they then realize 
ScummVM is a cool thing let's help there too, then that's great and we 
should of course welcome them. Opening such a door makes much more sense 
than treating people only interested about our core as second-class 
citizens. It is important to realize that if our core improves we also 
benefit from that.Thus, I see no reason to force them into joining a boat.

> At the opposite, I see essentially positive points in organizing the 
> efforts around the core code, under a ScummVM hat. sub-projects key 
> users would be identified and could be informed of changes by the core 
> team, could suggest new functionalities without getting flamed, and 
> they could ask for resources on punctual issues already handled by 
> ScummVM team: hosting, forum configuration, buildbot, whatever. The 
> other way round, I'm convinced that a new developer of such a sub 
> project would have better chances to contribute to ScummVM if he feels 
> he's part of the family.

I think I didn't talk about how we organize core development so far. But 
yes, having, for example, a mailing list to notify core users about 
changes and for them to bring in suggestions, is a good thing.I think we 
can talk about that again when we are ready for the actualy step. Thanks 
for these suggestions.

> The way we act currently, such a developer would feel completely out 
> of the game and wouldn't mind about ScummVM, except maybe for its core 
> changes.

If a developer using our core helps in making our core better, he *is* 
helping (and also contributing to) ScummVM and also himself. I have a 
feeling you make that sound like a bad thing simply because he isn't 
interested about ScummVM itself. In fact, I completely fail to see why 
it should be a bad thing that someone isn't interested in our adventure 
game engines (and thus ScummVM) and *still* helping the project.Making 
people feel bad about this definitly is not going to help us get any new 


More information about the Scummvm-devel mailing list