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

[Arnaud Boutonné]

If I agree it's not relevant to compare ResidualVM issues with the ones we
could encounter in another 2D retro-gaming reimplementation project, I do
not share the vision about the third parties.

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.

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

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.

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.

When I consider what could be done in term of economies of scale, poles of
excellence, community building and advertising, I'm completely convinced
it's a better direction than just saying people "we made fork easier, now
get lost".

Regards,
Arnaud


On Tue, Aug 13, 2013 at 1:26 AM, Johannes Schickel <lordhoto at gmail.com>wrote:

> On 08/13/2013 12:42 AM, Thierry Crozat wrote:
> > On 12 Aug 2013, at 22:19, "A. Milburn" <fuzzie at users.sourceforge.net>
> wrote:
> >
> >>
> >> So, the obvious alternative approach is simply for third-party projects
> to
> >> simply fork off a copy of the core and try and keep it in sync as needed
> >> (which is what ResidualVM does, for example).
> > The remarks from fuzzy bring a question though: will it be possible to
> > provide a core that can be used for other games without needing to be
> > forked and modified? It looks like Residual for example needed to modify
> > that core. How much would we be ready to accommodate changes needed
> > by others in the core code? And to maintain them?
>
> I think Residual is not the best example for diversions. We are fixed at
> 2D games, while Residual's major changes are for 3D games support AFAIK.
> Such "big picture" changes are nothing we should worry about too much, I
> would say. Trying to handle such things in a generic core would be much
> more work than simply focusing on what is fitting our basic setting
> (i.e. 2D games).
>
> I think a possible way to have others use our core code would be as
> follows:
>
> We have a repo for our "core". Third-parties will clone this repo and
> integrate their code into it (i.e. add your engines, your logo,
> whatever) and use the result as a official development repo. Whenever
> there are upstream core changes, they can pull them in by, for example,
> merging the upstream core's master into their repo. This is somewhat of
> a "soft" fork when they do not make any changes to our core.
>
> Of course, we need to assure that they will not have to edit files which
> are kept in the core repo to avoid any merge conflicts for "default" usage.
>
> How we maintain changes from third-party projects is a good question
> however. Then again, we can ask developers of third-party code who want
> to merge their changes into our code to maintain them as part of the
> "team".
>
> > And this also raises the question of whether this will make it more
> difficult to make changes that will
> > break engines, as not only in-tree engines would need to be updated but
> > also engines developed by others.
> >
>
> I think in an uncontrolled scenario it would be easier to break engines.
> However, in case of ScummVM engines we can still stick to the current
> policy of providing updates to/helping people to update their engines.
>
> In case of a third parties they would need to make sure that they update
> their engines. After all, its still their choice when to update to a
> newer core version. I think it is hopeless to make promises that we will
> adapt all the third party code out there whenever we have some possibly
> breaking API changes.
>
> Greetings,
> Johannes
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20130813/c6f2132d/attachment.html>