My 2p. This change process management is very difficult to get right.
Derrell I personally feel your pain, as I embarked on 0.5.3 development first and now have the additional overhead of evaluating a changing 0.6 branch. Presumably there will be some painful 0.6.1 and 0.6.2 etc. point updates even once 0.6 is released. But this is to be expected from many Open Source projects. What qooxdoo does have is a very talented team in Andreas and Sebastian et alia. This qooxdoo-devel mailing list is very high volume, and I'm amazed they have enough hours in the day to read them. We should let them get on working their magic without the overhead of mailing list consultation. They will be the best arbiters of what a 0.6 final release IS. Otherwise we'll argue about what is missing without having a broad overview. People will pop on and off the list as their use of qooxdoo dictates. New people will have the same queries over and over. We should await a 0.6 release and have an Interface freeze [Object Oriented talk]. The namespaces will allow isolation of further changes to a much greater extent. So some of what Derrell mentions should be applied on the run to 0.7 or 0.6.1. Perhaps in the time inbetween the 0.6 release the HOME PAGE should make it clear that work on 0.5.3 has stopped. Also, mention that 0.6 is a work in progress and if the developer doesn't like that, provide links to dojotoolkit.org --- Also it would be worth considering asking a user to identify what they want out of qooxdoo via a chart. Length of time of their project: - Short 0.5.3 - Long: 0.6, consider dojotoolkit in mean time Skill Level of Coder: - Javascript only: 0.5.3 - Able to use Subversion for project management: 0.6 Reason for using QooxDoo - stumbled across it: suggest dojotoolkit , openlazlo - looks like delphi RAD: mention that documentation is based on developer experimentation from examples. mention 0.6 is volatile but in progress - looks quite corporate: mention 0.6 is under progress and they will have to change a lot of their code to jump from 0.5.3 to 0.6 Terry. ----- Original Message ---- From: [EMAIL PROTECTED] To: Andreas Ecker <[EMAIL PROTECTED]> Cc: qooxdoo Development <[email protected]> Sent: Tuesday, 1 August, 2006 6:40:48 PM Subject: Re: [qooxdoo-devel] massive change process 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 ------------------------------------------------------------------------- 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
