On Mon, Jan 5, 2009 at 1:49 AM, Eric S. Raymond <[email protected]> wrote: > Ivan, I think your idea for gradually lifting Wesnoth C++ code to > Python is technically sound and would help address some serious > sources of defects in the Wesnoth codebase. > > However, you bave done such an inept and -- at times -- > arrogant-seeming job of presenting yourself that you have already > alienated some senior developers on this project in just the few days > since you've shown up here. By saying things like "If your ideas are > any good, you'll have to ram them down people's throats" in response > to legitimate questions about what you are doing, you have even very > nearly alienated me, the person who was championing your project.
Eric, I am very sorry for that. I regret this kind of behavior and will do my best to fix this problem. Thank you for championing my project and thank you for the honest rebuke (I deserved it). > I do not know whether this is a problem with your character or your > language skills. I hope it's the language skills, but you have a > way to go to demonstrate that. You need to show much better > ability to work with this group than you have so far. > > I am publicly rebuking you, rather than simply abandoning your > proposal, because I still think it's likely that this situation can be > salvaged to the longer-term benefit of the project. You have, after > all, actually cracked into a problem I had been eyeing with > frustration for nearly half a year. > > But, if we are to recover this situation, you are going to have to > do a minimum of two things: > > (1) Present a convincing work plan, and a justification for it that is > not merely an ungrounded claim that Python is better. Even I, Python > fan that I am, don't consider that a sufficient argument. >From a very high level perspective the Mozilla Firefox model is very close to what I have in mind if we replace XUL with WML and Javascript with Python. Internally Firefox is a XUL application written in a combination of high-level language and XML-based markup lamguage. They separated the engine written in C++ (they call one part of it "Gecko" and the other "XPCOM") from actual applications and they have very powerful plug-in model. I don't propose anything nearly as complex as XPCOM though. I see it as 1) a core C++ game engine with good python bindings and 2) actual "applications" (or "modules" as I call them now). With this in mind we can look at Wesnoth as "wmlrunner", a very high level interpreter for components written in Python/WML. This will open many new possibilities like a) more flexible plug-in model -- complete new authoring tools could be developed as Wesnoth plugins using the same GUI, b) overcome WML limitations and allow content authors to create new gaming experiences (like RPG elements: shops, character inventories). Further explanations and justifications will follow. > (2) Stop pissing off my colleagues off with IRC and email behavior > that makes it seem like you want to ram ideas down peoples' throats > without even arguing for them in any detail. Nobody gets to behave > that way here, least of all a project newbie. As I said, I am sorry for that. I will do my best to explain and justify my ideas in much more friendly way. > I am willing to cooperate with you in developing a work plan and > reviewing your code -- much as, say, a mentor for a Summer of Code > project would do. > > It has been suggested to me that I should simply work with you in > a separate repo. I don't think this is practical; merging trees after any > significant period of parallel development could be unreasonably hard, > and I think it would be unfair to put that burden on you even if you > have been behaving very annoyingly. > > Therefore, *if* you present a persuasive work plan, I will be willing > in the future to sponsor dev access for you and having your code put > on a branch in the project repo -- but with no promise about if or > when it will be merged to mainline, and the understanding that I would > be watching you like a hawk and the entire enterprise *would* be > scrapped if you messed up trunk even once. > > But you must present that work plan first. Not merely because you > need to answer technical questions, but because you need to show (a) > that you have a path forward that is incremental and reasonably safe, > as opposed to a doomed attempt at a "big-bang" all-at-once conversion, > and (b) you need to demonstrate the ability, and the willingness, to > work as part of the project team. a) I work on the work plan. b) I propose a slow incremental thoughtful conversion that would preserve good existing work as much as possible. Ivan Illarionov _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
