[Scummvm-devel] Port status?

Max Horn max at quendi.de
Tue Jul 22 05:47:45 CEST 2003


Am Dienstag, 22.07.03 um 13:57 Uhr schrieb 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
>
Good.

>  * 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)

Hm, how do you know? You sounds quite sure about the cause. BTW why is 
this not documented on the bug, though? Information like this should 
always be added to the bug!

>  * 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.
Again, how do you know it's really a walkbox issue? I see nothing on 
the bug report which justifies this; true, walkboxes *may* be the 
cause, but just as well there are half a dozen other possible causes, 
I'd not jump to conclusions to quickly.

I can't look into that one since I have no english Zak, and no interest 
in/time for playing through Zak till that point at this time.

>
>  * ZakRC 3 (#771499) appears to have you looking at it,
No I am most definitely not looking at it. I just answered to a comment 
hoenicke posted there. Letting hoenicke attach the script will help 
however is going to work on 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.
>
Again, hoping that some random developer a) is going to even look at it 
and b) is able to fix it, is just that, a hope, not a plan.


> 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.

I don't know where you draw that confidence for. Right now I see none 
of the above RC's being fixed, despite what you say. I'll believe they 
are fixed once they are fixed, not before.

>
>> 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,

Then you should define "freeze" better. To quote you: "We're going to 
hard-freeze (port & bugfixes -only-)". So apparently, that was wrong.

>  as the majority of it should be calls to the existing Config api.

As for the persitances-of-settings part, yes. As of the "can't set 
graphics mode" part, no.

> 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).
>
Erhm, then you should state that, and not assume we might now! Post to 
the item you mark as RC which parts of them you consider RC. Currently, 
the whole of bug #747984 is marked as RC. Nowhere does it indicate that 
only the persistence issue is RC.



Bye,

Max





More information about the Scummvm-devel mailing list