History for CMFProcedures
??changed:
-
<pre>
From [email protected] Thu Sep 27 10:29:35 2001
Date: Wed, 26 Sep 2001 15:33:43 -0400 (EDT)
From: Tres Seaver <[email protected]>
To: Chris Withers <[email protected]>
Cc: [email protected]
Subject: Re: [Zope-Coders] How to get going :-)
</pre>
On Wed, 26 Sep 2001, Chris Withers wrote::
> Not sure if this is the right list or not, but here goes anyway.
>
> So, with this community checkin stuff I have two ideas I'd love
> to get going on.
>
> 1. Integrate FS ZSQL Methods with CMFCore
Here is my take on the process:
1. Write a proposal for the change in the "approved" location
(the dogbowl for CMF, dev.zope.org for Zope). Solicit feedback
on the change from the appropriate mailing list. Small changes
(trivial bugfixes) don't require proposals, but should have
corresponding tracker / collector issues.
2. Update your sandbox to use a branch, which should be named
to indicate the purpose the branch serves::
$ cd projects/CMF
$ cvs tag chrisw-FSSQLMethods-base # remember our start point
$ cvs tag -b chrisw-FSSQLMethods-branch \
-r chrisw-FSSQLMethods-base # make the branch from it
$ cvs up -r chrisw-FSSQLMethods-branch # update the sandbox
3. Add the file to your branched sandbox::
$ cd CMFCore
$ cp /home/chrisw/FSSQLMethod.py .
$ cp /home/chrisw/test_FSSQLMethod.py tests
$ gvim tests/test_all.py # add the test
4. Ensure that all unit tests run against the sandbox::
$ cd ../Instance
$ ./zctl.py test Products/CMFCore/test_all.py
$ ./zctl.py test Products/CMFDefault/test_all.py
...etc
5. Commit on the branch::
$ cvs add CMFCore/FSSQLMethod.py CMFCore/tests/test_FSSQLMethod.py
$ cvs commit -m " - Add FSSQL methods."
6. Lobby for inclusion in the head (bugfixes and new features)
or onto the current release branch (bugfixes only). Lobbying
mails should be sent to the "area owner" ([email protected]
in the case of the CMF), and should include:
o URLs to the checked-in versions, using http://cvs.zope.org.
o URLs of the rationale for the changes.
Branched changes are most likely to be merged if they meet the
following criteria:
o Rationale policy was followed.
o The patch is minimal for the purpose (no gratuitous diffs!)
o The patch/feature is understandable.
o The patch/feature doesn't break any existing tests.
Policies may vary slightly based on the area of the site.
Tres