Hi Christian, On 01/11/2012 02:03 PM, panyasan wrote: > Hi, this is on the discussion we already had how to reorganize and > decentralize qooxdoo-contrib.
Yeah, and I feel it's about time we collect ideas and suggestions in a place better suited than the mailing list. Otherwise we will re-iterate similar statements and look up old discussions in Nabble over and over again [1]. I've therefore create a dedicated wiki page: http://qooxdoo.org/contrib/qooxdoo-contrib2.0 We can of course discuss items here on the mailing list. But if you have input that is essential and should persist, please add your ideas and thoughts there. [1] http://qooxdoo.678.n2.nabble.com/Git-solution-av-contributions-td7097543.html > I think it was already suggested to use an npm-like approach. Wouldn't it be > cool if we had following: I'm not sure. I suggested a catalog like PyPI. What characterizes an npm-like approach for you? > - the only information that is kept in a central place is a registry of > links that point to manifest documents; I would rather have one link that links to a root directory, where you can find a contrib-like directory structure with <version1>/Manifest.json, <version2>/Manifest.json, trunk/Manifest.json like we have it. Manifests characterize a library, not a contribution. (Whether people call the meta-information of a contribution also a "manifest" I don't care at the moment). > - a contributor locally creates a contrib, uploads it, for example, to > github, provides the address in the Manifest, and then executes "generate.py > publish", which would upload the Manifest to the central registry; These are many points in one: a) Yes, we should have a central registry, what I call the "contrib catalog". b) Yes, the contrib author has to maintain the contrib's information in the catalog in some way. c) To have the generator automate this is a nice idea. Maybe later ;-). > - to install the contrib, we would not have to provide the address in the > config.json, but simply the name and the version of the contrib, which would > then be downloaded from the appropriate url (which the application developer > doesn't need to know). Agreed. As I wrote before we can continue to use the existing "contrib://" pseudo scheme, which contains this information. > - There would be no more need to update the qooxdoo contrib wiki. All > contributions would be listed in a simple page generated automatically from > data retrieved via central repository. This would be true for the catalog. Whether there are other pages in the wiki pertaining to individual contributions is another issue. > This would also allow to remove > older, non-functional contribs automatically without cluttering the > "available contribs" page, thus also making clear how many functional ones > really exist. How could that be? > > > - Finally, even an automatic test suite would be possible, alerting > contributors about failures. This would force contrib developers to better > maintenance and improve the quality of the contributions (or remove them > from the list if they fail). I'm not sure I understand what you mean. One issue in the area of general tooling I see is the Contribution Demobrowser. What would an automatic test suite do? It would run through the contribs and run their individual tests, right? Because the automatic test suite can only run tests the developer has written, right?! But that would be quite a topic, as we would not only need 'generate.py test' but also 'generate.py test-run' in each contrib, right?! Thomas ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
