[Scummvm-devel] What is happening to the ScummVM team?

Max Horn max at quendi.de
Sat Feb 14 01:23:54 CET 2009


Am 13.02.2009 um 19:06 schrieb Jordi Vilalta:

> 2009/2/13 Max Horn <max at quendi.de>:
>> So, I think I should, for the benefit of myself and the project,
>> reduce my role and get others to work on stuff. For starters, we  
>> need:
>>
>> * a forum admin (or ateam) who also will look into upgrading our  
>> phpB2
>> (mainly for security reasons, phpBB2 gets no security fixes anymore  
>> --
>> in fact till very recently we had an old outdated version installed,
>> too)
>> * a wiki adming (or team) who does the same for the wiki: Installing
>> security fixes, and stuff
>
> While looking for Vex's "Developer web" information I've found some
> documentation on the "Hosted Apps":
> http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps
>
> MediaWiki and phpBB are already offered. I remember seeing someone in
> ScummVM mentioning them but I don't remember whether using them was
> considered. It looks like an interesting option: they handle the
> maintainance and updates, while I guess they leave some administration
> options open (like changing the skins).

We have discussed it back when they added the feature. Yes, we could  
move there, though one advantage of not moving stuff there is that  
this way not all our sites are hosted by the same company. We have  
been bitten by this badly in the past, so some diversity seems like a  
good thing. OTOH, the "free maintenance" is appealing, too. Would have  
to check whether they support adding custom Wiki plugins, though... Oh  
and for phpBB, I think they are using 3.0, so we'd also have to  
rewrite our theme. Something I'd like to see done in either case, see  
one of my previous mails. As usual, we just need to find "someone" *g*.


>> * another mailman list moderator or two wouldn't hurt, volunteers?
>
> What does this work consist on? I may be able to help with this.

Looking out for mails and subscription requests held for approval,  
filtering out the spam(bots) and admitting legit stuff. Not much,  
really, but if Eugene and me are swamped with work we can easily end  
up neglecting it at times..


[...]


>
>> Oh, and it would be nice to have some people who actively drive
>> improving ScummVM. Like, not just fixing bugs and adding engines, but
>> people who actively work on bigger stuff (and that includes finding
>> others to help with it, not just doing it alone), like
>> * getting 16 bit gfx support in
>> * revamping the midi/music driver stuff
>> * finally getting that keymapper / vkeybd stuff into a usable state,
>> somehow (maybe requires a rewrite, dunno)
>> * thinking about GSoC projects (new GSoC is around)
>> * coming up with new ways to improve ScummVM and working towards that
>> goal, actively
>
> It looks interesting. Maybe using the appropriate tools would help
> with this kind of stuff. For example, I think we should have a unified
> place where to track desired feature enhancements. Currently some of
> them are on the TODO wiki page, others are on the OpenTasks wiki page,
> others have their own wiki page, others are in some users' wiki pages,
> others are in SourceForge's feature requests tracker... I really like
> the format of the current OpenTasks page, but it isn't dynamic enough
> (one can't sort tasks by priority or add comments easily, for
> example). It would also be interesting to have some kind of vote
> system (for the devs) to see which are the most desired features.

While I agree that it might be nice to unify TODO page and the FR  
tracker a bit, I don't think that lack of tools is responsible for the  
lack of action, nor do I believe one second that adding them would get  
people started to work on projects :-). Or at least I'd be very  
surprised...



> I think trac (also listed in "Hosted apps") could be a good candidate
> (there are probably better ones, but it's the one I know). It has a
> simple but interesting roadmap system where you can associate generic
> "tickets" (which can be either bugs or tasks, for example) to a
> release, and it tracks the "release progress" depending on the
> associated tickets status. The pidgin team is using it to track the
> progress of big features or branches, in addition to releases. I could
> have a look at preparing it, if there's interest. If people don't like
> it in the end it seems there's an opt-out option which would leave it
> as it was ;)

I have nothing against trac, but again, it's only a tool and not going  
to write us code. Adding more management is nice, as long as you have  
something to manage. As it is, I fear we'd just end up creating tons  
of tickets which then sit there... and do nothing... I have seen  
countless projects where highly motivated people started creating  
elaborated and detailed roadmaps, feature plans, etc. etc., only for  
them to die silently because when it came to coding, they suddenly  
discovered nobody was there to implement their great ideas... :-)


I think we have plenty ideas between us all, but not so many people  
able / willing to realize them... :-)


Cheers,
Max




More information about the Scummvm-devel mailing list