[Scummvm-devel] Bringing our Core Code to another Level?
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
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
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