Hi Philipp, Dominik
Dominik, can you give a short overview what zope.generic
> > If you take a closer look at this package and you will see
> that each
> > subpackage is well documented.
> Right. But that information isn't easily accessible. You have
> to go to zope.generic/trunk/src/zope/generic/foobar. That's
> FIVE directory layers down from zope.generic!
Yes, that's true, but if you install only one package from
the 'zope.generic' collection you need to have that README.txt
in this package and not more then that.
> Another question I raise: Why are there subpackages in the
> first place?
> And what's the rationale for calling it 'generic'. It's be
> like calling it 'zope.fast' or 'zope.easy': you get no idea
> about the contents of the package. Of course, I know why it's
> called 'zope.generic'. Because it's a package *collection*. I
> think package collections (e.g. like zope.app or
> zope.products which we used to have some years ago) are a mistake...
I'm not sure if that is also right for the generic package.
The generic package is ONE concept which is implemented in
different reusable sub-packages which also can be used
as single packages for just one aspect of the generic concept.
> > The generic package collection is/was developed/mentained
> by Dominik.
> > The zope.generic sub-package are very well layered and have clear
> > dependency that's the reason why they are containd in a collection
> > package. I'm not fimilar with the state of the 'generic'
> project right
> > now. But it's a really cool concept.
> I'm not convinced that easily :). Perhaps sketching out what
> it really is and what its purpose is would help.
I think Dominik can explain the generic pattern. All I can say this
quickly, you can define new instances only based on schemas without
a class implementation. It's a kind of ZClasses, Archetypes in a
clean Zope3 like implementation. Generic means you can define generic
components which are initializable and configurable during the
runtime. There is also a pattern for enhance such a generic instances
via plugins. All I can say, it's generic ;-)
> >> * For example, what does the 'z3c' namespace package stand
> for? Who's
> >> behind this stuff? And why does it sometimes use 'sandbox' or
> >> 'Sandbox'
> >> instead of or in parallel of 'trunk' for its main
> development branch?
> > The z3c top level package is a namespace for additional
> packages where
> > I and Bernd started to use at the SwissEasterSprint.
> Great. This should be written down somewhere. (I'm not
> blaming you for not having done this; we have no rule for
> this right now. I think we should have a rule, though).
no problem, I agree to have a place for such infos.
The README.txt files are not good enough for give a overview
because you have to checkout first or browse the really slow
repos with a browser.
Tell me where is somewhere and I can write something ;-)
> >> - Do other people also think it'd be a good idea to come
> up with some
> >> repository guidelines? Stephan had a proposal about specifying
> >> package metadata and code maturity/quality, I think it's worth
> >> working towards easily accessible info like that. If others agree,
> >> then let's get started.
> > Not started, just make progress in what allready started
> with Stephans
> > proposal and the ZSCP implementation ;-)
> > Yes, I agree
> > Perhaps you can check the proposal and see what we did in
> > http://svn.zope.org/zf.zscp/. I guess there is more to
> implement but
> > right now it's working and very professional looking.
> > Thanks to Kamal Gill for the great desing work!
> I'm not as much looking for a website that gathers all the
> ZSCP information as much as for guidelines that help us
> maintain a certain quality of documentation within the repository.
I think the proposal from Stephan should catch all your questions.
If not feel free to define and propose them. I agree with have a
more clear process for all you are asking.
> >> - Should this be part of the Zope Foundation development process
> >> (which again seems to be worked out by the Zope Management
> >> Organization)? If so, I'll hereby volunteer to join such a
> >> and contribute my ideas (especially on package organization in the
> >> repository and the associated development process).
> > I really hope that we adapt the prosess described in Stephans ZSCP
> > proposal.
> > ?rev=6
> > 6671&view=markup
> > Whould be cool if we could make progress on what Stephan
> started with
> > the proposal and your ideas.
> Yup. I'll reiterate over Stephan's proposal once again and
> provide my comments.
Zope3-dev mailing list