[Scummvm-devel] Merging remaining GSoC branches (Attention PORTERS!)

[John Willis]

> Hi folks,
> 
> with 1.2.0 released, it is time to look into merging the remaining three
GSoC
> branches.
> 
> The decompiler task
> ===================
> This can be merged right away from my point of view. Yes, it still needs
> work and polish (and I still hope Michael will find some time and
inspiration
> for that, or for at least writing down a summary of all the TODOs, ideas
and
> plans we were throwing around during GSoC). But it is good enough already.
> I'd like to clean up my SCUMM v5 "plugin" for it, and put that in as well,
but
> writing it I learned that some things in the decompiler should ideally be
> changed before we start writing more engine plugins for it... So I guess
we
> need a roadmap, a more up-to-date TODO, and then ideally some
> volunteers ... ;)
> 
>  To get the branch, use
> 
>    svn co
> https://scummvm.svn.sourceforge.net/svnroot/scummvm/tools/branches/
> gsoc2010-decompiler

Great, it seems daft not to just go ahead and merge this in.

> The OpenGL branch
> =================
> Johannes recently merged trunk back into that branch, but since then a
> couple new engines were added... ;). That's a minor bit, though. More
> importantly, we got some new SDL-based backends since the branch was
> created. Now, one of the things the branch does is refactoring the SDL
> backend, modularizing it. This is IMHO a great thing for all SDL-based
> backends, but it also means that they all need to be adapt. Hence, several
> backends in the opengl branch are likely to not compile. Hence
> 
>  >>> every PORTER/MAINTAINER of an SDL based backend is strongly
> encouraged to check out the branch, via
> 
>    svn co
> https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm/branc
> hes/gsoc2010-opengl

A few of us are hacking around with this branch and (IMHO) there may be a
few things that make it undesirable to commit into trunk just yet.
I know Jordi has been looking at OpenGLes for some backends he was working
on as have I (OpenPandora, I'll merge in the GLes variant of the backend as
soon as I get it doing more than corrupt screens ;-)).

Joost and I also planned to talk about this branch shortly and maybe cram
some hacking time in.

> As I see it, we have two alternatives to proceed:
> 1) Set a deadline until which we expect porters to have fixed up their
> backend, then merge.
> 2) Merge the branch ASAP, and let porters fix their ports on trunk.
> With 1, we reduce the time some ports are broken on trunk (which is good
> in terms of reducing the time testers cannot get at working daily builds
to
> test new engines on non-standard platforms; but I am not sure whether
> there are really that many of these?). On the other hand, it might be more
> convenient for some porters to fix their port on trunk, and by merging the
> changes, buildbot will help expose any breakage. A compromise might be to
> set a relatively short deadline, say 2-4 weeks, with the option for
porters to
> shout loudly if they need some more time to get a fix done. Opinions? Esp.
> from affected porters? :)

Subject to a review of what is in the branch and some regression tests
option 2 gets my vote.
 
> The plugins branch
> ==================
> As far as I know, this is mostly ready for a merge, too. Though it would
be
> good if the people who know could chime in. Also, we need to determine
> whether to merge it before or after the OpenGL branch. If we decide to
wait
> a couple of weeks with the OpenGL branch, I'd propose to merge the plugins
> branch first, and as soon as possible.
> 
> One thing we may have to look out for is the Nintendo DS port, which, I
> think, as usual received changes on the 1.2.0 release branch which have
not
> yet been merged back to trunk... (side note: Neil, I am still not very
thrilled
> about this practice, which makes testing trunk that much harder. The last
2-3
> times I performed the merge for you, but I'd appreciate if you could do it
> ASAP, and not just before 1.3.0 is coming. Right now it should only be a
> couple minutes of work.) Anyway, that means that merging the plugins
> branch could potentially conflict with the 1.2.0 changes. Just something
to
> watch out for.
> 
> To get the branch, do
>    svn co
> https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm/branc
> hes/gsoc2010-plugins

I think this has already been extended and tweaked on the branch. 
It seems that just getting it in ASAP would be the best way to proceed and
fixing the flack as we go. 
Considering how much it touches the DS area I would also love to see Neil's
changes in before any merge however.

Regards,

John