On Mon, Jun 28, 2010 at 6:45 PM, Christian Theune <ct@gocept.com> wrote:
So I'd like to open up the floor to everyone who ponders participating and express their wishes/hopes/expectations for the summit. Don't start your engines trying to solve any specific issue right now. Try to abstain from bikeshedding. Think of this as the preliminary brainstorming to figure out what we want to talk about at the summit.
Since nobody else wrote anything, I'll get started - feel free to skip this, as it's gotten long :) - Agree on a process for larger feature changes in "Zope". Things like zope.publisher vs. WSGI, changes to zope.interface semantics, security without proxies, the NoZCML movement, ... - we need to have a way to talk about these in a structured way, document things, create opportunities for feedback from various stakeholders and get a definitive answer on whether we allow it or not. There's different options for how exactly such a process might look like, but I think we definitely need one. - Recognize the weekly Zope-dev IRC meetings as an official voice of the Zope community and declare our support for the decisions we make in these. I think effectively that is what we have today, but it is currently not spoken out. We might want to make sure that certain important decisions do get a mailing list discussion, so that people who cannot attend the meeting have an opportunity to provide their feedback. This needs to be balanced carefully, so we don't get open-ended bikesheds on the mailing lists. - Try to find a way how we can communicate cool new things we do in the various projects. planet.zope.org is currently a bit empty and didn't even mention things like Grok and BB releases. Following the developer mailing lists of each project costs too much time, so it's currently extremely hard to know what others are working on inside the Zope community. I think we share too little knowledge and experience with each other. This could lead to ideas for further improvements and changes to Zope. What lessons have people learned in building RESTful interfaces, Web 2.0 UI's, what strategies on "decomposable UI" like zope.contentprovided / zope.viewlet have actually worked or whatever. The Zope packages have little to offer when it comes to "new" Web technologies but arguably that's one of the main things they are used for. I cannot think of anything else right now. There's always bikeshed topics like Python 3, Subversion vs. DVCS but I don't think talking about those at the current stage has much point. Hanno
Hi there, Thanks for kicking off this discussion, here's my "old grump" response. :) On 06/29/2010 05:24 PM, Hanno Schlichting wrote:
- Agree on a process for larger feature changes in "Zope". Things like zope.publisher vs. WSGI, changes to zope.interface semantics, security without proxies, the NoZCML movement, ... - we need to have a way to talk about these in a structured way, document things, create opportunities for feedback from various stakeholders and get a definitive answer on whether we allow it or not. There's different options for how exactly such a process might look like, but I think we definitely need one.
A way to support more drastic innovations in Zope? It's hard to make decisions when there's no code yet, and it's hard to start writing code when there's nobody to make a decision that might ever lead to such a change. I just know what I've been working on: * a new publisher * iface to replace zope.interface and zope.component I think deciding upon such directions as a community can only be done in a very broad sense ("we want to replace the publisher"); as soon as you get into details you might get a few useful ideas and then a lot of bikeshedding (or nobody talking). Whether such changes will ever make it will depend on a small group of people doing the initial work and then doing some marketing. I've been going around the Zope project for years now to get anything innovative done; the community in zope-dev only seems to support maintenance work that everybody can more or less agree on (and we have trouble even with that). I think in a large measure this is all right: the Zope project shouldn't radically change at every whim of a developer. It should however support a community in which developers can experiment with more radical improvements and then adopt them back again. We should support innovation better, and have a way to consolidate innovations back into the ZTK. Candidates include: * the work surrounding zope.sqlalchemy and z3c.saconfig; both already represent consolidations of earlier SA integration work. * Chameleon replacing zope.pagetemplate, and deprecating zope.pagetemplate? * javascript resource handling: we have zc.resourcelibrary, and hurry.resource (radically improving the former), and z3c.hashedresource. Most web frameworks aren't even aware that they need such features yet, but we've had them for a while. megrok.resource integrates them all in a usable way for Grok, but we could adopt this more widely. (But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
- Try to find a way how we can communicate cool new things we do in the various projects.
Good point. We used to have such ways: Conference presentations and dedicated Zope sprints. Let's have a few more of those? And putting more life into planet.zope.org would certainly help too. Regards, Martijn
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
(But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
YUI 3's loader comes to mind (as its the one I have most experience with). -- Sidnei
On Mon, Jul 5, 2010 at 2:56 PM, Sidnei da Silva <sidnei.da.silva@canonical.com> wrote:
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
(But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
YUI 3's loader comes to mind (as its the one I have most experience with).
Ditto for dojo. :) Jim -- Jim Fulton
On 07/05/2010 09:32 PM, Jim Fulton wrote:
On Mon, Jul 5, 2010 at 2:56 PM, Sidnei da Silva <sidnei.da.silva@canonical.com> wrote:
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen<faassen@startifact.com> wrote:
(But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
YUI 3's loader comes to mind (as its the one I have most experience with).
Ditto for dojo. :)
All javascript libraries grow their own packaging systems... I'd be nice if they were all compatible with a more neutral version. Some consolidation would be nice, plus bridging all of that to the Python packaging world. I'd envision a JSON-based metadata system that include intra and inter package dependencies between resources, a way to wrap these packages, a package host along the lines of PyPI, and integration with the Python packaging system. And then wrap all these javascript libraries up and upload them to the package index. The wrapping up can be fairly straightforward (YUI contains a dependency graph), or need analysis. Regards, Martijn
On 07/05/2010 08:56 PM, Sidnei da Silva wrote:
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen<faassen@startifact.com> wrote:
(But hurry.resource is not perfect; I think it'd be better to step out of Python land and create a Javascript packaging system somewhat modeled on Python's, with easy integration into Python projects. A sprint task?)
YUI 3's loader comes to mind (as its the one I have most experience with).
I've used YUI 2's loader (and hurry.resource was inspired by it). I don't know YUI 3's loader so I should take a look at it. (It strikes me that whatever its technical merits, a javascript packaging system will have to appear neutral politically and YUI's loader won't do that. The YUI 3 loader is connected to the YUI global object?) Anyway, YUI's loader only solves part of the problem - at least the YUI 2 loader doesn't feature a packaging system, just a loading system. I want the ease of saying: "my project depends on YUI version blah" and having YUI version blah being there, just like I can do for a Python package. Such a package should include a dependency map of the included resources as well, not just the code. Regards, Martijn
participants (4)
-
Hanno Schlichting -
Jim Fulton -
Martijn Faassen -
Sidnei da Silva