[ZF] Please comment! Re: Zope Development Process
Jim Fulton
jim at zope.com
Wed Sep 27 06:23:28 EDT 2006
There have been very few comments on this. This is important.
Please let us know what you think. We need input from more than the
usual suspects.
On Sep 25, 2006, at 5:44 PM, Jim Fulton wrote:
> Section 7 of the Zope Foundation By Laws,
> http://www.zope.org/foundation/ZopeFoundationByLaws.pdf, calls for the
> establishment of a Zope Management Organization (ZMO) and a Zope
> Development Process (ZDP). It is through these that the bulk of the
> Foundation's activities seem to be governed on a day-to-day basis. We
> haven't established either of these yet. In addition, the ZMO is
> supposed to establish Architecture, Planning, and Requirements
> councils made up primarily of representitives of members of Project
> Management Committees. Section 7 makes passing reference to top-level
> projects, projects, and subsystems. Exhibit D of the Membership
> Agreement,
> http://www.zope.org/foundation/ZopeFoundationMembershipAgreement.pdf,
> also refers to project charters. It is not clear whether a project
> charter is something that applies only to top-level projects.
>
> This is a *lot* of organization. :)
>
> We need to put some processes in place soon. Some issues that need to
> be addressed soon include:
>
> - We need a process for allowing people to contribute their code to
> the source-code repository.
>
> - 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.
>
> - We need a way to invite committer members.
>
> The first two issues are pretty urgent, as I don't think we can
> establish a Foundation repository without resolving them.
>
> Exhibit D of the membership agreement provides a process for
> establishing committer members. This has a number of problems:
>
> - It makes no distinction between membership and commit access. A
> committer member is given access to the repository *after* they have
> made substantial contributions. If the contributions are source
> code, they can't make them without access to the repository or
> without getting someone else to check in code on their behalf. I
> really want to discourage people from checking in other people's
> code. If their contributions aren't source code, then there is no
> point in giving them repository access or in calling them
> committers.
>
> As I've menntioned before I *really* want to separate membership
> from commit access. In earlier reading of these documents, I'd
> thought that commit access and membership were not coupled, but
> rereading exhibit D, I realize that I was wrong. :(
>
> - The process requires project-management committees and projects,
> which we don't have yet.
>
> 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.
>
> I wonder what projects there should be. Do we need want many
> projects? Some obvious projects are Zope 2, Zope 3, and ZODB. 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? For
> example, zc.ngi is an experimental testable networking library that I
> plan to use in ZEO someday. Should that be in the repository? Should
> it be a project? Should the packages in the zc (or z3c or lovely)
> namespaces be their own projects? Should each namespace be a project?
>
> Thoughts?
>
> 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
>
>
>
--
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