[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