<div class="gmail_quote">On Thu, Dec 1, 2011 at 9:53 PM, Johannes Schickel <span dir="ltr"><<a href="mailto:lordhoto@gmail.com">lordhoto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/30/2011 09:31 AM, D G Turner wrote:<br>
> If we exclude engines regularly, we encourage our userbase towards using<br>
> unofficial builds from third-parties, which is IMHO more of a<br>
> support/maintenance headache for developers i.e. bug reports on unknown<br>
> code, than just having the code in tree, where we can fix it.<br>
<br>
</div>I assume when you talk about "engines" in this paragraph you mean<br>
additions to engines already in the main ScummVM tree?<br>
<br>
At any rate I fail to see about what developers you talk about. When we<br>
get a bug report on something not in the mainline, we politely point out<br>
that we do not support this and that the bug reporter should talk to the<br>
developer of the code. So where's headaches for us? On the other hand if<br>
the original developer gets a bug report he might maybe get a bug<br>
report, which triggers some bug in code not by him, but then again he<br>
could ask us about it and last but not least tracing this down is not<br>
really different when we would get that bug report. Then again you talk<br>
about having the code in tree then, so it shouldn't really be related to<br>
code we already have in our tree. So I fail to see the point here. But<br>
maybe you can explain it again for me please?<br>
<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Last but not least, we could use this argument to include every change a<br>
user made, but which we don't really like/want/can merge. So not sure if<br>
it's really any good for arguing to include a engine or not.<br></blockquote><div class="im"><br>But in these cases we use pull requests. So I'm not sure how this relates to the argument at hand.<br> <br>
> However, this should be done on a case-by-case basis with code review<br>
> etc. prior to merging. LordHoto's engine merging procedure which is now<br>
> on the wiki covers all these points, and since the EoB subengine looks<br>
> to be in good shape with the games completable, merging this should not<br>
> be an issue.<br>
<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<sarcasm>Oh my engine merging procedure is on the wiki now. Maybe then I<br>
should change it to reflect to how I exactly think we should handle that<br>
instead of what we agreed upon.</sarcasm><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>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).<br>
 <br>Regards<br>Filippos<br></div></div><br>-- <br>"Experience is the name every one gives to their mistakes" - Oscar Wilde <br>