[Scummvm-devel] KYRA - Eye of the Beholder extension
Johannes Schickel
lordhoto at gmail.com
Thu Dec 1 20:53:20 CET 2011
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?
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.
> 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>
// Johannes
More information about the Scummvm-devel
mailing list