[Scummvm-devel] Port status?

[J.Brown (Ender)]

> > The hard-freeze will hopefully last a week, and we'll release on the
> > 1st
> > or so. This of course requires the remaining 5 (3 ZakV2, 1 Simon, 1
> > general) RC bugs to be fixed.
> >
> I don't think that's realistic. First off, just sitting around and
> "hoping" that somebody might fix those bugs, will *not* get those bugs
> fixed.

Of course, however:
 * The Simon1 bug is being looked into by Jamieson already, and can be
worked around easily enough if a solution is too volitile, and the proper
fix applied to 0.5.1

 * ZakRC 1 (#770699) is a behavioral problem with setting the camera
position. Again, worst case is we can implement a hardcoded 0.5.0
specific hack to set the camera position  after the room 0 irising
from that particular script, and add a proper fix in 0.5.1. I'll look into
this one further tommorow, if I finish cleaning (I'm moving rooms atm)

 * ZakRC 2 (#771483) is a real bug, and I cannot suggest a hack without
more knowledge of the walkbox code than I posess. However a documented
workaround (whilst tricky and definatly a disturbance of gameplay) does
exist.

 * ZakRC 3 (#771499) appears to have you looking at it, or if you end up
not having time would probably be a good one for some random developer to
try his teeth on. In terms of a 1 week deadline, I'm pretty hopeful it can
be fixed by then.

So, worst case is we release with bug #2 (that's one RC critical bug, but
one that has a workaround that can be documented). The others should
easily be at least easy enough FIXME jobs. I am just trying to encourage
people to give these bugs a shot.

> Also note that fixing those bugs might require bigger changes (or not).

And if they do, we will consider whether the changes are too risky to be
made during the second freeze period or not.

> > Do we have any volunteers to fix bug #747984? (Launcher general options
> > dialog is a dummy)?
>
> If you want to get that fixed, I don't see how you can do it. This is
> not a bug, after all, it's a missing feature. Code will have to be
> added, possibly the backend API be modified So it's not allowed during
> the hard freeze, per your own rules.

Code being added during a hard freeze is subject to the code in question.
Fixing up at least a portion of the Dialog and removing the rest is very
very possible even during a hard freeze, as the majority of it should be
calls to the existing Config api. Remember, any commit can be vetted by
myself or you. Although I do not WANT any spurious commits, 'trivial'
fixes are not going to be rejected if they are obvious improvements needed
for 0.5.0 (Yes, a *fully* functioning dialog with OSystem queried scaler
selecion, etc, may require backend and other changes. However I just want
the basic functionality).

 - Ender