[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[55130] scummvm/trunk/configure

Max Horn max at quendi.de
Fri Jan 7 13:59:03 CET 2011


Hi there,


Paul, you raise some important points; points that I have been worrying about for months now, and that caused a lot of bad feelings on my side. Maybe it's time to talk about some of these now.

Johannes already mentions some of this, but I'll try to summarize what I think.


The part of ScummVM work that is most fun is adding new cool stuff: RE'ing a new engine; maybe writing a completely new backend. THe part that is least fun is maintaining stuff, polishing engines / the UI, hunting down and fixing weird bugs, keeping an engine up-to-date, working on the plumbing, etc.. All this is *very* understandable, IMO. Yet, for the end-user, the not-so-fun part is at least as important as getting new games supported. Indeed, if the new games are playable, but buggy and incomplete, well... then the user gains nothing. Then we just spent tons of time on REing effort for nothing but ourselves. Heck, why even make this stuff public if we don't work on polishing it up to a releasable state? Where is the *point* in adding an engine if we are not sure that it will ever get to a end-user ready state?

We have several existing engines (and a few ports) that sit there and semi-rot. Now, you may rightfully say that by not adding a new engine, we won't fix those old engines; we won't make anybody work on them. This is correct. 

But I'd like to avoid mistakes from the past. These days, I'd like to only add engines if I know they have a future; it's not enough for me that they have a past. With git, it'll be so easy for me to review engines even outside the main tree, and preserving history won't be an issue anymore either. This is so because it seems to be very difficult to get rid of an engine once it has been added.

Now, I do understand that adding an engine early to the main tree has some big pros for the engine developer(s). But it also has some cons for the guys working on the plumbing and infrastructure. Those guys won't don't have the fun part, you know ;). So, let's try to evaluate some of them:

* Keeping the history intact: Merging an engine late in its development cycle into SVN is annoying if you want to keep the history.
My Solution: Switch to git. Much better no matter what we do.

* Working on the main repos (I'll call it "master" from here on) gives you access to buildbot.
You could set a VM up as alternative, but yeah, that's more work than just using buildbot. Esp. if you want the same coverage... But consider this: It was a lot of work to setup buildbot, and now it's super hard to find anybody willing and with the time maintain that. The plumber guys would like to get some help with that, but people are busy having fun doing RE work... So what's in there for us? :)

* Working on master gives you extra helping hands: True in some regard. For myself, I always feel obliged to make sure *all* engines still build when I make a change. I always compile with --enable-all-engines, and if I refactor stuff, I try to fix all engines before committing. So every new engine adds to my burden. But OK, we can fix that: If we agree that it's acceptable to break disabled engines (meaning: disabled by default in configure), then that would remove one blocker for adding more new engines from my POV. I'll just refactor enabled engines.

And if the engine is kept in a separate git fork, this is a no-issue, of course, as it would be the problem of the guy maintaining the fork to pull in my refactoring and adapt his code?

* What else do you consider a pro for merging engines to master early on? Extra helping hands? Well, you can get those on your git fork of master, too, it's very easy for them to work on your tree, isn't it? Extra code review? Well, I scaled my code review back on new engine code, because I got yelled at too often for it: "Stop complaining, this is code in progress and we'll rewrite it later on anyway!". OK OK, but how am I supposed to know when and when not code review is permissible? Heck, in fact, I think all of us have a right to do code review on *anything* that goes into master at any time, without ever having to justify that.


Long rant, short end: I am OK with being very permissive about adding new engines, *if* we setup some rules for that. Here is a suggestion: 

Every new engines would begin its life in "disabled state" on master.  Authors of new engines agree to ensure their engine gets completed. We define what that means (game completable with at most minor glitches, sufficient integration into the ScummVM framework, endian safe, works on multiple platforms; which platforms of course depends on the specs of the games).

To achieve this, one or more persons become official "maintainers" of the engine. This may be distinct from the list of engine authors.

An engine in "disabled" state always must have maintainers. If you can't work as maintainer anymore, it's *your* job to find a successor (of course as others may help, if they feel like it, but it's the maintainers duty). If you don't find a successor (because there is none, or because you don't have time, or because you just don't care, which of course you are free to, as a volunteer), we flag the engine as "unmaintained" for a certain period, say 6 months. The team may decide during this time to try to find new maintainers from inside or outside, but doesn't have to. If no maintainer is found during that time, we remove it from master again. If a new maintainer is found, we give a probation time, during which some progress should happen, else we will remove the engine anyway.

Once the engine is deemed "complete", it enters the "enabled state" phase of its life. The role of maintainers now changes: They now promise to maintain the working engine, feeling responsible for addressing bug reports. Doesn't mean they have to do all the work; just that you then would feel responsible for either fixing the bug yourself, or finding somebody to do it, etc.
If this maintainer becomes unavailable without successor, we then once more flag the engine as unmaintained, but since it is completable, we will keep it, and keep it enabled. We would maintain a list of "unmaintained" engines somewhere, with a permanent "job offer" written there, and maybe e.g. in the SF.net "jobs" system and other places. If we undertake serious refactoring that require some knowledge of the engine to test it, however, we might have to demote it from "enabled" to "disabled" state. I'd like to avoid this as much as possible, but if we just can't find anybody to fix it, and adapt it to code changes, and to test it, well, we gotta drop support. If that happens, I would suggest keeping it in the repository anyway, since it used to be enabled; and to try to find a new maintainer.

A similar approach could be done for ports.

My hope is that this won't take the fun out of it, but it'll weed out those engines that are only fun-for-developers projects, and for which nobody cares to turn them into something that is also fun-for-users.


Bye,
Max



More information about the Scummvm-devel mailing list