[Scummvm-devel] KYRA - Eye of the Beholder extension

Filippos Karapetis bluegr at gmail.com
Thu Dec 1 22:13:50 CET 2011


On Thu, Dec 1, 2011 at 9:53 PM, Johannes Schickel <lordhoto at gmail.com>wrote:

> On 11/30/2011 09:31 AM, D G Turner wrote:
> > If we exclude engines regularly, we encourage our userbase towards using
> > unofficial builds from third-parties, which is IMHO more of a
> > support/maintenance headache for developers i.e. bug reports on unknown
> > code, than just having the code in tree, where we can fix it.
>
> I assume when you talk about "engines" in this paragraph you mean
> additions to engines already in the main ScummVM tree?
>
> At any rate I fail to see about what developers you talk about. When we
> get a bug report on something not in the mainline, we politely point out
> that we do not support this and that the bug reporter should talk to the
> developer of the code. So where's headaches for us? On the other hand if
> the original developer gets a bug report he might maybe get a bug
> report, which triggers some bug in code not by him, but then again he
> could ask us about it and last but not least tracing this down is not
> really different when we would get that bug report. Then again you talk
> about having the code in tree then, so it shouldn't really be related to
> code we already have in our tree. So I fail to see the point here. But
> maybe you can explain it again for me please?
>
>
David is talking about maintaining and syncing more code bases, which is an
additional burden for engine developers. If for example there is
refactoring in one branch, there should be in all the other branches as
well, which translates to additional burden for the original engine
developers, i.e. more spare free time, that not many of us have available.


> Last but not least, we could use this argument to include every change a
> user made, but which we don't really like/want/can merge. So not sure if
> it's really any good for arguing to include a engine or not.
>

But in these cases we use pull requests. So I'm not sure how this relates
to the argument at hand.

> However, this should be done on a case-by-case basis with code review
> etc. prior to merging. LordHoto's engine merging procedure which is now
> on the wiki covers all these points, and since the EoB subengine looks
> to be in good shape with the games completable, merging this should not
> be an issue.

 <sarcasm>Oh my engine merging procedure is on the wiki now. Maybe then I
> should change it to reflect to how I exactly think we should handle that
> instead of what we agreed upon.</sarcasm>
>

I specifically asked for clarifications regarding non-adventure game
subengines (like EOB) when this procedure was added in the wiki, but people
said that this would be too verbose and/or strict, so this part of the
discussion did not reach to a conclusion. So, I believe that we ended up
saying that these subengine cases are reviewed on a per-case basis - at
least that was my understanding from the original discussion (which also
referred to other subengines, like Geekwad).

Regards
Filippos

-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20111201/0279a99c/attachment.html>


More information about the Scummvm-devel mailing list