[ZF] Please comment! Re: Zope Development Process

Jim Fulton jim at zope.com
Wed Sep 27 17:56:04 EDT 2006


Philipp von Weitershausen wrote:
> Jim Fulton wrote:

>>> - We need a process for allowing people to contribute their code to
>>>   the source-code repository.
> 
> I guess this means the following questions:
> 
> a) How do you become a contributor (and do they have to be ZF members 
> first, or become ZF members at the same time, etc.)?
> 
> b) How do contributors contribute code?
> 
> Right?

Yes.

>>> - We need a process for contributing 3rd-party code to the
>>>   respository. (I would like to see this kept to a minimum, if
>>>   possible, by using eggs, rather than code copying, to manage
>>>   dependencies on 3rd-party code.
> 
> Hmm, I wonder what this means. Are you talking about companies like ZC 
> doing open-source rounds by importing stuff into svn.zope.org? Or are 
> you talking about projects like docutils, pytz, mechanize, etc. whose 
> code we reuse.

The latter.

> In the former case, I think it's desirable to put stuff in svn.zope.org. 
> In the latter we should stop maintaining vendor imports indeed and just 
> rely on their eggs.

Yup, but that may not always be possible or desirable. A case in point
is Stephan's import of IBM XML data for ICU.

>>> - We need a way to invite committer members.
> 
> Who are, afact, not the same as contributors, right?

Right, depending on whether you agree with the current ZF docs or me.

>>> We need to find a way to move forward, either by interpreting and
>>> following requirements set forth on these documents, or by trying to
>>> simplify them and following the result.
> 
> How can us IANAL folks help?

You can have opinions on how you wnt this sort of thing to work.

...

>>> What about smaller efforts?  Should ZConfig be a separate project?  
>>> If not,
>>> what project does it fall under.  It is used by all 3 of Zope 2, Zope
>>> 3, and ZODB.  What about a project like zc.buildout?  Should the
>>> repsository contain code that doesn't fit under any project?
> 
> How about creating a "framework project" that maintains stuff like 
> zc.buildout, ZConfig, zdaemon, etc. It would be good having a "pope" or 
> at least a 'maintainer' for the common infrastructure we all use.

This is like the "Other" project that Martijn suggested.  See my
response to him, when I get around to making it. :)

...

>>> Should it be a project?
> 
> No, too many projects would kill us.

You are probably right.

>>> Should the packages in the zc (or z3c or lovely)
>>> namespaces be their own projects? Should each namespace be a project?
> 
> That sounds like a good idea to start with.

This actually has some issues that I'll raise in a separate note.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Foundation mailing list