Hey,
finally I have the time to get back to such a important topic, event if the
last mail in this thread has been some time ago. First of all, the feedback of
all of you shows me that you all care about that topic which is a really good
point.
I think I have heard on thing in all the discussions: the current system is not
good enough but I think before talking about solutions and why one solution is
better than the other, we should focus on the flaws that the current system has.
Christian did a good job in his initial post be summing up some of the flaws
and I agree on most of the points. Especially the need to update the checksum
is too cumbersome to do it each time. There is already a bug report about that
[1] which needs to be fixed. But that hasn’t been done up until now which
brings me to a good point Petr mentioned in a post:
The problem I see is that qooxdoo tries to be for everything, which is simply
impossible to achieve for the current dev-team.
This is one of the main problems we currently face. The whole code base grew
over the last almost 10 years and is now quite huge. This includes a lot of
maintenance which is why the dev speed decreased in the last couple of years.
Additionally, I want to quote John:
q/qxweb is not compatible with any nice UI widgets, so for “thin” front end I
use requirejs, jquery, knockoutjs, etc … and a home made qx.Class. I agree
that Qooxdoo is not really suitable for that kind of development, but mostly
because the qxweb provides very little compared to what is already out there
and more established.
I agree with John here and this is what concerns me most. Just take a look at
the JavaScript frameworks popular nowadays like ember or angular. There is less
what they have in common with qooxdoo. We also monitor the download stats and
this is decreasing as well.
So in my opinion, the framework needs to do big steps in the future to get it
back to a level where we can compete with other frameworks. And the contrib
system is one of these steps but you will all agree, that this does not need to
be one of the first steps. A good conritib system is worthless without
contributions. Which brings me to a thing Christian wrote:
I'm also very much in favour of using an existing package manager.
I agree with that but not only for package managers. The open source community
evolved and a lot of cool stuff has been created and built within the last
couple of years and we haven’t been able to get any benefit out of that because
we do have a lot of custom approaches. With bower e.g. twitter implemented a
contrib system for all of web development but we could not participate of that
because we have another way of integrating dependencies. We see such things all
day as soon as something cool and new comes up we usually can’t use it out of
the box.
To cut a long story short, we currently focus on getting the framework to the
next level and we don’t have the manpower to get all done you suggested. But as
this is in the end a open source project, we would be happy if someone want to
take care of that. Of course we would be available for discussions and for some
help but most of the stuff could be done by the community as you know you needs
best. One of the first and most obvious tasks would be to get rid of the
checksum for master versions in the contrib catalog. A pull request for that
topic would be highly appreciated.
Another quick win could be commit rights for the contrib catalog in order to
circumvent pull requests. Just send us a note so we can add you as committer.
Regards,
Martin
[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=8524
Am 10.09.2014 um 16:45 schrieb Dietrich Streifert
<dietrich.streif...@googlemail.com<mailto:dietrich.streif...@googlemail.com>>:
Hello everybody,
I've tried to follow the discussion and I have to say that I'm just lost
on all those possible options, implementations and versioning stuff.
I've just did a few JSDoc corrections do UploadWidget on sourceforge [1]
via svn which where reported in an issue at bugzilla from Christian
Boulanger.
I'm currently using 3 contributions in my project, the aristo theme by
John Spackman, SmartTableModel by Derrell Lipman and of course
UploadWidget by Tobi Oettiker, Petr Kobalicek and me.
My "strategy" is to use manually checked out contributions to local
directories with manual references in the config.json file via the
libraries key. Til now my source was sourceforge.
Now I've seen that there is an (from my point of view) outdated
uploadwidget contrib on github [2] where Derrell already has made those
changes which I've made today :-(
I suspect that the github version and the sf version already evolved to
subtle differences. That's odd.
Regards
Dietrich
[1]
https://svn.code.sf.net/p/qooxdoo-contrib/code/trunk/qooxdoo-contrib/UploadWidget
[2] https://github.com/qooxdoo-contrib/uploadwidget
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
