[Scummvm-devel] RANT
Eugene Sandulenko
sev at scummvm.org
Sat Jul 22 19:58:22 CEST 2006
On Sat, 22 Jul 2006 16:22:30 +0200
Max Horn <max at quendi.de> wrote:
I was too busy with my daily job in last days, so unfortunately I
completely missed this case. Now I had to read backlogs but it seems
that some actions were inside of heads or in private mailings/messages.
Or maybe it just summed up and Max broke.
I will try to explain things, my vision here, my goal is to do my best
to improve in this situation is team relationships.
Sorry for overquoting, I just feel difficulties with chopping sentences
in understandable fashion.
> one last response: While I still think that (ab)using displayName()
> for file access, is a bad idea, fact is that FilesystemNode is
> missing an additional name() method that can be used for filename
> lookup / comparison. This lack caused me to abuse displayName() in
> the SCUMM game detector, too, BTW (albeit in a lesser fashion --
> just for comparing to a list to known filenames, not for use in
> File::open). The main reason I haven't added FSNode::name() yet
> (which would be very easy to do, after all) is that I was afraid of
> it silently getting abused -- by people using it in File::open.
Overload it with method which will consist of error(). Simple as
that. Unless I misunderstood you.
> Unfortunately, I still do not feel like starting a discussion on the
> design here, simply because I strongly believe it will lead to
> nothing anyway.
There is indeed a problem with it. However we really splitted work here.
It just seems that developers are really afraid of breaking OSystem.
When they were invited to the Team, they were told not to overuse their
commit access and discuss all significant changes out of their working
area.
It seems that it clashed with the very nature of a human, laziness. I
imagine like developer X thinks: 'I don't have time to go deeply into
OSystem code, moreover I could be mistaken, so better I'd go easier
route and use existing methods'. This includes looking into other
engines, and it seems what happened with LordHoto.
It really seems to me that this had changed in last time. Developers
and porters started to contribute to glue code. Also in my opinion (and
I conducted negotiations/passed ideas/explained how things work in the
Team to almost every new developer which came in last 2 years or so),
you boys got matured as a developers, and in 99% cases commit quality
code. This means that you should not really afraid of touching other
code like Osystem. Moreover, commits get reviewed in most cases, but
I'll talk on this later.
> Last night I just wanted to throw everything down and stop doing
> anything with regards to ScummVM at all. Well, but I don't like
> abandoning something w/o any warning or transition, as that's unfair
> to the other people involved. So I will "fix" this particular issue
> in Subversion now.
irc> <@Fingolfin> anyway, enough ranting for tonight. I simply think I
irc> should use my little spare time on other more redeeming efforts.
irc> There used to be a time when my changes actually were helping
irc> ScummVM (like refactoring it and introducing the Engine class - I
irc> am not sure we'd ever have moved to more than Simon and SCUMM w/o
irc> that). But nowadays, I think I am just making a fool out of
irc> myself. Like behind my backs people are whispering "look at that
irc> latest commit fingolfing made. Isn't it silly how he rearranges
irc> code that works just fine w/o any immediate benefit, just because
irc> he thinks it's help future ports or engines? Stupid one, that!"
Oh yeah. People are lazy. Lazy. And even more lazy. When they are
forced to do something, they always will complain. They could abstain
from expressing their complains aloud, but if they're 16 years old,
they usually haven't learned to do that. Remember, newborn humans
always complain very loudly. They usually learn self-control much later.
> But I am tired of having to constantly monitor all commits to find
> out if somebody runs into troubles with any of our backend/engine/
> middle end code.
> Apparently, things work "good enough" w/o me worrying about fixing
> the real problems instead of curing the symptoms (I guess I am too
> much like an OpenBSD designer here, and not enough like a Linux
> hacker).
irc> <@Fingolfin> (this is *not* meant personal against LordHoto or his
irc> code, BTW, I am just tired with the way ScummVM is developed...
irc> i.e. by lots of independant people working on their own engines or
irc> backends, and nobody really having a plan or vision on how the big
irc> picture should look, not even anybody trying to or caring for one)
ScummVM is big. And if you mention Linux here, even it got patch
reviewers, however their rules are not so strict.
I'm really up for OpenBSD way, and I think that we're going exactly its
scheme. Just take a look at it from different angle. We have engines
there, we have ports and we have glue code. Each engine has more than
one person working on it and they discuss how they will do things,
they got engine maintainer, main person who leads the work. If a port
got more than one developer, same thing happens there too.
As of our glue code, we know who is the one with whom we should discuss
it, that's you, Max. Nobody but you could do it properly. You have a
wide vision which affects not only whole ScummVM code base, but also its
future. So if you would stop working on it, we will be in a big trouble.
You are the maintainer. Endy doesn't have enough time in last several
years and I don't fit it because of lack of knowledge of proper OO
paradigm and mainly because of lack of time.
> I realize that adding a new port is much more fun than redesigning
> OSystem or improving the existing SDL backend to properly cope with
> errors (during res switching, for example -- think transaction
> rollbacks), and that adding a new engine is more fun than fixing &
> improving the savegame system.
Oh yeah. All engines we added in last time except lure and kyra were
added by poor sev. One of them even was expelled from the project ;).
Also most of new developers were invited to work on either new engine or
new port. So far only project leaders contributed most of our glue
code. That's our load and we deliberately signed for it.
> What I realize now is that I can't
> force interest in these on anybody. So I'll stop trying, and will
> turn passive for the time being.
I think that you're wrong here. You have the experience and expertize.
In practically all cases you contribute close to perfect ideas. Often
there is not much to say. Human nature plays its role here as well.
However some may not agree here, but people feel themselves better when
they are put into borders and got clear rules and directions. Not
everyone got enough guts to complain about our course. In most cases
that's plainly because we're going in the _correct_ way. Few remaining
cases are not enough competence, not enough knowledge on the code et al.
Max, just stop for a bit and remember the feature we discussed many
times. That some day we may split OSystem into independent project.
However I personally think that it will never happen de-jure, but it
already happened de-facto long ago. Take a look at GTK+. Most projects
which use it never contribute code to it. They don't even know about its
internals. They may even abuse its methods. But when some nice feature
appears in next version, they often switch to it, otherwise they will
use what is already exposed in documentation.
Same thing is with OSystem. Even our porters, who should really express
more thoughts about particular features as they will have to implement
them, do that on rare occasions. There are several reasons, one of them
is that we already have 20+ ports, and we got experience. We know what
will not work for everyone and avoid it. That leads to fact that
porters act in same way, i.e. use methods which are already present
(remember that ConfMan abuse). But even here we have good sparks of
life, take a look at Neil and his DS port.
> I think I am often too discouraging with my strong opinions on
> certain subjects, so people are deterred from working on e.g. the
> glue code. So my attitude is simply unrealistic. That's not nice, but
> I gotta face it.
I don't agree with you on it. We had this discussion internally several
months ago, but you already changed your way, i.e. you choose more soft
ways of expressing your correct opinion now. Also I spoke with those
people who misunderstood you and took your comments personally. Please,
continue doing this. If you wouldn't do it, we'd never reach this
success, we'd never reach 250k downloads just in 2 last months.
Other boys and girls, i.e. the Team. Please, communicate. Most of you do
that properly on IRC. I.e. you nod, "aye" and 'ok' on others' words.
But you do it rarely on -devel. And I am guilty here as well :).
> Therefore, I'll grant myself a timeout and will stop monitoring,
> will stop making cleanups or refactoring or working on the middle
> end, or anything like that.
I try to monitor all commits as well, but I just can't do it as good as
you do. It seems that other devs do it close to never and check only
their own subprojects aka engines and ports.
> Most everybody seems content with the
> current state of things anyway, so my efforts seem misplaced.
No, that's not complete picture. Most everybody is content with current
_route_. If we will stale on it, it will be wounding to the project.
> I turn myself into laughingstock, and cause additional work for
> myself and everybody else, which is little appreciated.
Hahaha. Really funny. I remember that several folks jumped into
#scummvm and shout 'scummvm sucks' (not literally). So what? Again,
often there is nothing to say on your perfect code improvements, and
often you're the one who sees design flaws and fix them later.
Also it is easier to inspect existing and working code. I know, it's
not a methodological approach, but lack of time and formal education in
IT industry plays its role here.
So, Max, please, look around. We're in a good shape now. Almost all
active developers now are 'new blood'. Most of our old-timers are busy
with their real life. We all need a good lead, who will express his
constructive critique, and you was so far the best person to do it. Be
over people's complains and just continue your work.
Eugene
Yet another ScummVM Team lead
More information about the Scummvm-devel
mailing list