[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