Burak Arslan wrote: > thron7 wrote: >> Wait, this is more far reaching then just adding another API. You want >> to re-structure the existing classes. >> > > yes, i don't like the idea of qx.io.remote.Soap. > >>> i guess this point this merits an enhancement bug. i can file a bug >>> report if you think i should. >>> >> >> I'm not the right one to judge this. Maybe others like Andreas or Fabian >> can comment on this. >> >> > > won't bet on it :/. > >>> i can say that this code doesn't derive from mateo casati's client >>> anymore, it's rewritten. there are code fragments here and there, but >>> the logic is completely different. >>> >> >> Then why do you maintain the copyright notices in the code and readme?! >> >> > > because i'm not sure, i'm no lawyer. as i said there are still code > fragments lying around here and there, so i try to be as honest as i can.
Fair enough. But then the code fragments can either be re-written and the copyright notices removed (especially since you say that the logic is completely different). Or the copyrights have to stay, and then we have to address that. > >>> well, as i did not get any feedback about the current state of the >>> soap api, i can't freeze it, and i won't write documentation for an >>> unfrozen api. >>> >> >> I think you're wrong here. Documentation is not something nice and extra >> which you add as an icing at the end of the development cycle. We don't >> follow the waterfall model anyway. Documentation is an intrinsic part of >> any piece of software, at any stage of its life cycle. Documentation is >> necessary to convey what the software is about and how to use it. You >> write a piece of software and the docs at the same time (and the tests, >> if you're really into it). If you change the software, you change the docs. >> >> > > this is just one way of doing it. what we normally do is to freeze the > api before writing a single line of code. then the analyst(s) write > the tests and the documentation, and the coder writes the code. This is pretty much water fall: design upfront - coding follows suit. > we try to avoid refactors like plague, because they are costs without > value-adds. this doesn't mean we don't do them, but it's still an > indication of a poor design process. I wouldn't say they're without value since you gained insight and experience on the way leading up to them. Also, I don't consider it a poor design process, it's just a different approach. In many cases known to me upfront design was simply too unreliable and turned out to be full of flaws once the implementation takes shape, but there may be settings where this is not the case. But there is a whole literature about water fall vs. iterative development models, which we probably don't want to iterate over here. > > those being said; i can't find proper documentation on how you guys > work, nor about what model you follow. where do the ideas come from? > who converts them to tasks and prioritizes them? who assigns them to > people? what's the reasoning behind changes? i know none of those -- > we just watch the commits happen. Well, this surprises me, since although our documentation on the issue is probably a good deal from exhaustive, there is the Commiters Guide (http://qooxdoo.org/documentation/general/committers_guide), which covers a lot of ground, the role of the project lead and task-oriented development using the bug tracker, among other things. I thought you knew that. > eg. the change about the caching behaviour came out of nowhere. http://bugzilla.qooxdoo.org/show_bug.cgi?id=2354 The bug was filed nearly 3 weeks before any user-perceivable change was commited to trunk. Moreover, this is also a penalty you pay working on bleeding-edge trunk code :). > i tried to give feedback but saw that my assumptions were wrong, so > what i said turned out to be nonsense. my time wasted -- as well as yours. I cannot remember my time being wasted on that issue. I don't consider feedback or questions, even if they turn out to be misunderstandings, to be wasteful. Communication is a vital part of any project, and communicating means dealing with people's concepts, whatever they are. Currently, I'm dealing with your concept of a development process, and I think it's a very important thing to do, whatever the outcome may be. > > python does a better job of dev-community management, imo. see > http://www.amk.ca/talks/python-dev/ or python.org/dev. Yes, but how big is Python compared to qooxdoo?! > again: i can write documentation. doing it once is fine and i agree > that it's part of a proper contribution. but if ever you don't like it > and want me to change it, i won't bother, sorry. it's not fun, i'm not > learning anything anymore. I have the impression that you have very explicit ideas about what you want to spent your time on. You don't want to do documentation twice; you don't want to work with code that is formatted in qooxdoo style; you want to fullfill a spec and never look back. All that is fair enough. But if you want to deal with us, you probably have to make compromises, since we do things differently. You wouldn't expect us to jump ship, just to make it easy for you, or would you?! > > so: i'm willing to donate my time to improve qooxdoo, only either: > > 1) you give me voice in the design process so i can be sure the api > will stay my way. Even if you have a voice in the design process, there is no way of being certain that anything will stay. And this holds for all of us. > 2) you give me what interface to implement, and i'll do it. I'm not sure. We are usually not setting up specs and give them out. A lot of work and consideration is actually in coming up with designs, not just implementation. Thomas > > > best regards, > burak > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
