[ZF] Please comment! Re: Zope Development Process

[Christian Theune]

Hi,

I'm not sure this fits in here:

At the last DZUG conference, we had some input and discussions that
Institutions from Germany would be willing to sponsor specific
development projects run by the foundation. We're currently planning to
have a round table in January to gather about 5-8 of those institutions
together with representatives of the ZF. Maybe this would be a good
place to get some input from as well?

Maybe this is a totally different topic, but I think it's related ...

Jim Fulton wrote:
> 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. :)

And it needs to be transparent.

>> 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.

That's my impression too. On the second issue: Maybe we can have a
3rd-party repository that acts as a mirror. My biggest concern would be
that repositories that manage software we depend on go away or don't
provide historic versions that we need anymore. Something like a sandbox
for non-ZPL code maybe?

>> 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. :(

Ack.

>> - 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?

Do we have an idea of a schedule? Do we want those to be in place this
year, Q1 next year, ...?

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/foundation/attachments/20060928/b15714dd/signature.bin