[Zope-Coders] How to get going :-)

[Chris McDonough]

> What sort of tests should be aimed for with community checkins?

Tests that exercise the public interface of classes defined in the new or
repaired modules.

> where's zctl.py nowdays? does it come with documentation?
> Is the process for running the Zope tests the same or should I use
> testrunner.py?

This is a good question.  For now, I'd pick an existing test module and ape
its structure.

> >   6. Lobby for inclusion in the head (bugfixes and new features)
>
> Ah, okay, so community contributors should never merge to the head? Who
> should do that?

I dont think that's true... for features, there should be discussion before
the changes are merged into the trunk and the current release branch.  But
then you should probably do it after getting permission from the "owner" of
the package to which you're making changes.

I think basically what it boils down to is this for Zope core issues (as
opposed to CMF issues):  If a patch or feature is 'big' and you even
*suspect* that it will have documentation and/or interface impact, you need
to get permission from the module owner before checking it in to the trunk
or the release branch -- always do your development on a development branch;
OTOH, if its a bugfix situation (something that has no interface or
documentation impact) where you're not sure that your patch is "right",
email the Zope-Coders list to get "direction"; OTOH, if it's a bugfix
situation where its just a nobrainer, just check the fix in to both the
trunk and the current release branch.

This is basically the way we operate internally at ZC (person and list names
changed to protect the innocent).

- C