[Scummvm-devel] Understaffing (Was: What is happening to the ScummVM team?)

[Johannes Schickel]

Hi,

Max Horn schrieb:
> regarding release / code quality: I concur, things seem to have gone  
> downhill when it comes to testing coverage, code/release quality, and  
> also availability of ports / testing of ports before the release.
>
> In short, the reason for that seems to be understaffing / lack of time  
> of people.
>   

Actually that is understandable but it is IMHO no reason to force 
releases, like it seems to be the case with the last releases.
I think unstable / bugged releases will have a worse impact on our 
reputation than a release less a year.

> It starts at the top: The two team leads (eugene and me) are super- 
> busy with life outside ScummVM, leading to a certain regretable lack  
> in leadership. And in bug triage. It might be nice to add 1-2 new  
> people to the head of ScummVM. We'd need somebody very active and able  
> to fill in the leadership role. Management is understaffed resp.  
> existing staff lacks time.
>   

I guess this is the least important point. If all other developers test 
their code properly we do not need too much managing seeing that our 
code base is mature enough for most tasks. Maybe we should add some 
guidelines / tips on various work processes.

> It continues with engine maintanance: Not all our engines are being  
> very actively maintained. Right now, there is *nobody* assigned to BS1  
> (though I'd hope that the engine is stable enough to work well  
> anyway). Regarding e.g. the MM v2 bugs: 1-2 years ago I probably would  
> have already fixed those, as it is, I don't have time (other things  
> have higher priority for me) to even start debugging them. There are  
> some other people actively working on SCUMM, luckily, but I am not  
> sure how interested/equipped they are in/for fixing bugs in MM...  The  
> engine teams are understaffed resp. existing staff lacks time.
>   

Actually I guess if an engine is not maintained the probability that 
regressions are introduced is low. Of course there could be possible 
regressions when code in common/ etc. is changed and the engine would 
need to be adapted. But apart I guess regressions are mostly introduced 
because someone working on an engine changes / adds functionality. If 
that is the case we have of course someone with knowledge about the 
engine. I guess the problem here is really that not every person working 
on an engine is interested in all games supported by that engine :-/.

> It leads (but doesn't stop at) ports, where once again some ports  
> won't make it, for other ports we have heard little to nothing from  
> their porters. We certainly could stand getting some new people aboard  
> here! People like Chrilith, Neil, Kostas, etc. are working alone on  
> their ports, and the testing alone puts a huge burden on them. Port  
> teams are understaffed resp. existing staff lacks time.
>   

I talked a bit with Joost about releases and we came to the conclusion 
that unit tests and/or a test engine to test certain backend / common 
code parts might help to find regressions in backend and common code. Of 
course someone would need to work on that.
Not that I am not aware of our current tests in test/ but it misses 
functionality to test for example graphics output, FS code, SearchMan 
code (related to FS code, just remember the latest problems on Wii and 
PSP with it), etc.


> I'll reply to the other point in another mail, as this is IMHO getting  
> difficult to track otherwise. :-)
>   

Understandable as I also stated in my "PS" :-).

// Johannes