On 2 Mar 2009, at 16:33, Martijn Faassen wrote: > What is the Zope project? The Zope project is an umbrella project for > a number of sub-projects. Its source code is in a repository managed > by the Zope Foundation. Within the Zope project, there are a number of > projects that ship full-stack web frameworks (or application servers):
One of the most striking things about the Zope community (imho) is that we don't have a single central presence. There's no Zope conference, people go to PyCon, EuroPython, PloneConf, etc, they hang out in different irc channels (personally I discuss Zope in #plone, #zope, #zope.de, #plone-framework and #repoze), and this mailing list isn't widely read. Yeah, the people are mostly the same, and you know a Zopista from people outside the community, but there doesn't feel like there's a central community. I couldn't tell you what the Zope Foundation does, for example. > To distinguish between these two perspectives on Zope 3, we will > introduce a new term: "the Zope Framework". "Zope 3" should be used to > indicate the Zope 3 application server that is one consumer of these > libraries. To be explicit we encourage the use of "Zope 3 application > server" to indicate Zope 3 and discourage the use of "Zope 3" to > indicate the Zope Framework itself. +1 > The Zope Framework has a central status within the wider Zope > project. It is the core Zope technology ingredient to Zope projects > such as Zope 2, Zope 3 and Grok. With it's own IRC channel and mailing lists, that become the canonical place for questions about the ZCA, etc? Either way, +1 > A library that at some point in time is considered to be part of the > Zope Framework is called a "core library". The Zope Framework contains > those libraries that are reused by a large number of projects, or that > the Zope Framework developers want to promote to be being more widely > adopted. The Zope Framework developers especially favor inclusions of > libraries that are used by other Zope projects. +1 on everything but the "want to promote" bit - the libraries will be decided by the same developers they'd be promoted to. I'm -1 on framework bloat to help spread libraries. If a package is truly useful as part of the framework it goes in, if it's just cool I don't think it should. > The set of libraries that is "core" can change over time depending on > how these libraries evolve and are used. New libraries considered to > be "core" can be added to the set, and existing libraries once > considered "core" can be removed from the set. We should be careful > though, as we cannot just drop libraries from the core without > considerable thought. A library being in the core signals a level of > commitment to this library. Meh, ish. I think if we make it clear enough in advance we should be fine. If a non-core library is widely used compatibility will have to be maintained, but it doesn't mean we should keep it in core if it doesn't deserve it. > * if it has a lot of people who contribute to it from our community, > it's likely core. -1, it's a zope community package, but not necessarily part of our framework. > * if it's something we want to encourage more consumer platforms use, > it's likely core. -1, as stated above. > Which libraries should be core to start with? Proposed is to take the > ``zope.*`` libraries. We can immediately weed out a lot of libraries > that aren't considered core, and we can then start the slower > processes of adding and removing from that set over time. zope.* is a good start, but I think it'd be more useful to look at what packages are actually used by everyone that's considered to be a framework user. > Libraries may have a different status in the core to convey extra > information about them, such as deprecation status. How will this be signalled? > As a service to the users of the Zope Framework, the Zope developers > also make available lists of version numbers of core libraries that > have been tested to work together as a "Known Good Set". This receives > a version number and is the Zope Framework release. +1 How will the numbering convention work, currently it is in step with Zope3-the-application-server. > Currently intermixed with the Zope Framework core there is code that > implements a particular user interface, the Zope 3 ZMI. There is a > consensus that these application-like parts should be removed from the > core set, as that code typically only sees use by a single consumer > (the Zope 3 application server). It is not used by other consumers of > the framework. +1 > Examples of "extra" libraries are the "hurry.query" library for > constructing catalog queries, the "z3c.form" related libraries for > form generation, and the "grokcore.component" library which contains a > different way to configure components. Sounds sensible. > Any library that is developed for integration with the Zope Framework > in the Zope repository can be considered "extra"; "extra" is the set > of libraries that is not in the Zope Framework but can work with it. > By > having an "extra" designation we can more easily discuss such > libraries. What about other dependencies? Should we have a list of blacklist packages/things that prevent something being called an extra? What if it only works with 1 user of the framework, or 2, or all but 1, where do we draw the line? > The Zope Framework Steering Group is there to provide leadership for > the development of the Zope Framework. The Zope Framework Steering > Group consists of a small number of developers. The Steering Group > takes on the task to represent the interests of the consumers of the > Zope Framework. The Steering Group searches for consensus in the > community of users and contributors and thereby guide the evolution of > the Zope Framework. +1, I think they should be pretty hands-off, but I think it'd be valuable to the community to have people who feel responsible for pushing Zope forward. > It also resolves deadlocks: in > case of disagreements within the community about particular > development decisions, the Steering Group can make a decision based on > what it believes is in the best interest of the current and future > users of the Zope Framework. How is the steering group selected? How long do they serve for? All these questions need to be answered in a way that everyone considers fair for this to work. > The Steering Group is > there to act as a catalyst for the community, enabling cooperation, > helping to make good decisions, to have a positive atmosphere, and so > on. Hear, hear! > In order to > determine who is in it we could devise an election procedure by Zope > Foundation members. -1, I'm not sure the foundation membership is representative of the users. I'd say people put themselves up for election, there is a secret public vote, the foundation review the results and then appoint people. That way they can overrule the public but are informed by them. > Matt _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
