[EMAIL PROTECTED] schrieb: > Andreas, thanks for your comments. I want to reply to just a few of them: > >> For some other tasks commonly involving deep understanding of various >> core features or critical internal changes, it is also impractical to >> have a in-depth discussion first. We will try to have those cases down >> to a minimum. Still, we need to have the communities' and fellow >> developers' support for and trust in our work. Complex tasks often >> require actual tackling and trial and error rather than purely a prior >> discussion. We work on transparency, but please bear with us. ;-) > > I don't believe that there is any lack of trust in your work! You guys do > awesome work. That doesn't preclude, however, the possibility that > alternative ideas from outside of your small group there could yield even > better results. The in-depth details of what's to be done needn't be hashed > out on the mailing lists. I, too, work by tackling the job at hand and > getting it done. (I personally use a first-cut at coding as my design stage, > much of the time, but I also have no qualms at all about tossing out a few > weeks or more of work when I come up with a better solution.) What would be > nice to have on the mailing list prior to the start of work is the overall, > "Here's what we're planning on doing" description,
Maybe a list like qooxdoo-contributors could help. But as we already mentioned, complex tasks often require actual tackling and trial and error rather than purely a prior discussion. > and allow a bit of > discussion on that. That didn't exist this round. You had a very brief > announcement that things would be disrupted for a while, but no real > information about what was planned. Having done that, at a minimum, would > have given me much more of a "warm and fuzzy feeling". We didn't know at this time, what's exactly we want to do. Maybe we had have written "We improve the structure of directories and files." But that's relatively less meaningful I think. > >> Nobody loves either longer class names (see feedback for namespaces branch) >> or a deeper file structure _per se_. Often it is not a matter of personal >> likes or dislikes (that could sparkle a lot of discussion). It often comes >> as a necessity in any sufficiently complex framework. > > Ok, but there appear to be degrees of necessity. :-) Taking one example of > what I guess you thought was a necessary change, can you explain what the > *necessity* was of adding an extra "frontend" level of the hierarchy? Having > the "backend" split off made sense; it's not the primary 'product'. Having > "frontend" seems unnecessary to me and just adds to the unwieldy, long path > names. To clearly separate frontend and backend. For me it's just unacceptable to mix these stuff. backend in the old directory structure doesn't separate well from the frontend part of qooxdoo. Yes, the frontend part is the primary product for now. But maybe the backend stuff grows even more. Even if this is a directory more, it doesn't make things more complex to use. Just more organized. The makefile for example is one critical point of the old directory. One could think it also builds the backend part, which was never true. I hope you will also assert the benefit of this change later. Maybe I'm just a organization-freak ;) > >> Agreed, it could have been done that way. But it did not have to. It is a >> development branch after all, and as I mentioned above, it was not expected >> that the actual modifications would take so long. It has been announced that >> the branch will be unstable for several days and how people could still use >> the previous revision. > > Yes, it's a "development" branch, and yet we want all new-comers to be using > it rather than the 0.5.x branch at this point. Do we really want this. I'm not that sure. The migration scripts does as less 80% of work to convert between 0.5.3 and 0.6 later. So I think one could develop better with 0.5.3 currently. But this is just a personal preference. > Given this latter desire, the > "development" branch should, except for very short periods of time, always be > in a state where it is usable. Also, a "development" branch where only a > couple of the developers can do any development because they're making massive > changes (and everyone else just has to wait for a week or more) is > inappropriate. Forking a temporary branch to do these massive changes is > trivial in svn, and completely eliminates the problems of doing what was done > here. But then you must merge the stuff from the old namespaces branch to the development branch. Yes, forking is easy in general. But merging is complicated sometimes. > >> A development branch does not have to be stable at any time. That is also >> true for any snapshot of the trunk. A trunk from KDE also doesn't compile >> successfully each day, for example. > > Yes, but there's a BIG difference. The KDE developers do not want new users > to be using their development branch. They have released code that everyone > except those looking for the bleeding edge should be using. I think the same is true for qooxdoo. "namespaces" is the bleeding edge. Nobody needs to use it currently. The choose which version to use must be done on one's own responsibility. From my point of view the supported version is always the last major version - not any development branch. > That is not the > case here. Every new person who starts using 0.5.x now is going to be highly > annoyed in a very short time, when 0.6 is released and they have to do > whatever porting the automatic upgrade scripts don't do for them. Highly annoyed? Why? Yes, the switch to namespaces is maybe complex. But less complex than the switch between qooxdoo 0.1 and 0.5. We have migration scripts which does the job to 80%, this wasn't true for any earlier version of qooxdoo. Nobody needs to immediately to update. If you want to keep your applications up-to-date however, it's maybe a good idea, to always use the last major version. In general I think switches between major versions of libraries requires additional effort for the application developer. > I have been > repeatedly telling people not to do new development with 0.5.x; to use > 'namespaces' instead. Am I on a different wavelength than you are? Maybe. 0.5.3 is stable, documented and supported. Development branches, like namespaces, generally improves fast, but also are just not usable from time to time. > >> qooxdoo owes you a lot for your contribution, collaboration, well, and >> patience, > > Thanks. Cheers, Sebastian > > Derrell > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
