Jean-Baptiste BRIAUD -- Novlog wrote: > > >> qooxdoo contrib >> contrib has always be seen as an incubator, just read the main page [2]. > > Too much a self organizing incubator. Aligning tons of plugins is the > Eclipse's mistake. > I would not like this becoming Qooxdo's mistake to align tons of contrib > for tons of things. > Note : I only used backend contrib. > > Let me share some thoughts : > 1. we need a searchable catalog for all contrib (currently, only a svn > checkout and complete code browsing might do the stuff) > 2. what will be the difference from contrib A and contrib B that are > supposed to do the same thing (according to Wiki) ? > You don't know before testing = you don't know before spending hours and > hours testing trying ... > Exactly like Eclipse. You want to use SVN ? OK, there are several plugins. > Which one to choose ? Try ... > That's a hell and that's only the beginning : > 3. Dependencies and update. > Current contrib (only SVN ?) look like RPM package on Linux. APT is far > better : it manage the searchable catalog and manage update for you. > What "thing" will manage the dependency and the update of the contrib I've > choosen ? > I would not like to have to pool SVN HEAD to be aware of news. Also, HEAD > is unstable and dangerous. > 4. State. Some contrib are more like abandonware but as a user, you don't > know. > You have to lose half an hour just to notice that contrib doesn't take > care of the lastest version of Qooxdoo. To check if it is stable, you have > to loose at least half a day. > > => contrib is good but it need improvements on how to manage them (maybe > there are big differences between browser and backend one) >
Good points. That is why I think we need a web application like the demobrowser to manage the contribs. By coincidence, I know an excellent framework that is there to create web applications ... :-) Such an application should have snippets of code that you can copy & paste into the config.json. So, the contrib usage could really take off. Make it as easy as you can for the user. I'd be happy to contribute, but I won't be able to write that myself - in particular since I would write it using qxtransformer, which may not what you would want for the core framework. And let me say that I read all the contributions on this thread as implicit praise for the work that has been done so far on the framework, given the limited resources of the core team. We are all thankful for what qooxdoo has allowed us to do. I think the general mood is that the further development of qooxdoo will gain from listening to the (often conflicting) feature requests voiced by the community, and I understand that the devs are willing to do that as far as their resources allow it. The discussion reminds me a bit of the "cathedral" vs "bazaar" development model - qooxdoo surey is more on the "cathedral" side of things currently, with all the advantages that has - unified and well-thought-through architecture, strong support, stability, etc. But of course it means it is harder for the community to contribute. But we're trying hard ;-) (And don't misunderstand the lack of comments to the news as a lack of interest. I always read it, but would find it strange to comment each time. I'd rather post on this list). C. -- View this message in context: http://qooxdoo.678.n2.nabble.com/speed-of-development-tp5168583p5181165.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
