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 impractial 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, 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". > 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. > 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. 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. > 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. 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. 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? > qooxdoo owes you a lot for your contribution, collaboration, well, and > patience, Thanks. 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
