FrontPage
»
RepositoryProjects
»
CMFProcedures
From [email protected] Thu Sep 27 10:29:35 2001 Date: Wed, 26 Sep 2001 15:33:43 -0400 (EDT) From: Tres SeaverTo: Chris Withers Cc: [email protected] Subject: Re: [Zope-Coders] How to get going :-)
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:
- 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.
- Update your sandbox to use a branch, which should be named
to indicate the purpose the branch serves:
$ cd projects/CMF $ svn cp svn://svn.zope.org/repos/main/CMF/trunk \ svn://svn.zope.org/repos/main/branches/chrisw-FSSQLMethods-branch # make the branch from it $ svn switch svn://svn.zope.org/repos/main/branches/chrisw-FSSQLMethods-branch # switch the sandbox to the branch
- Add the file to your branched sandbox:
$ cd CMFCore $ cp /home/chrisw/FSSQLMethod.py . $ cp /home/chrisw/test_FSSQLMethod.py tests/
- Ensure that all unit tests run against the sandbox:
$ cd ../Instance $ ./zctl.py test --dir Products/CMFCore $ ./zctl.py test --dir Products/CMFDefault ...etc
- Commit on the branch:
$ svn add CMFCore/FSSQLMethod.py CMFCore/tests/test_FSSQLMethod.py $ svn commit -m " - Add FSSQL methods."
- 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 owners" ([email protected]
in the case of the CMF), and should include:
- URLs? to the checked-in versions, using http://svn.zope.org.
- URLs? of the rationale for the changes.
Branched changes are most likely to be merged if they meet the following criteria:
- Rationale policy was followed.
- The patch is minimal for the purpose (no gratuitous diffs!)
- The patch/feature is understandable.
- The patch/feature doesn't break any existing tests.
Policies may vary slightly based on the area of the site.
Tres
Re: [Zope-Coders]? How to get going :-) --[Tres Seaver
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:
- 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.
- Update your sandbox to use a branch, which should be named
to indicate the purpose the branch serves:
$ cd projects/CMF $ svn cp svn://svn.zope.org/repos/main/CMF/trunk \ svn://svn.zope.org/repos/main/branches/chrisw-FSSQLMethods-branch # make the branch from it $ svn switch svn://svn.zope.org/repos/main/branches/chrisw-FSSQLMethods-branch # switch the sandbox to the branch
- Add the file to your branched sandbox:
$ cd CMFCore $ cp /home/chrisw/FSSQLMethod.py . $ cp /home/chrisw/test_FSSQLMethod.py tests/
- Ensure that all unit tests run against the sandbox:
$ cd ../Instance $ ./zctl.py test --dir Products/CMFCore $ ./zctl.py test --dir Products/CMFDefault ...etc
- Commit on the branch:
$ svn add CMFCore/FSSQLMethod.py CMFCore/tests/test_FSSQLMethod.py $ svn commit -m " - Add FSSQL methods."
- 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 owners" ([email protected]
in the case of the CMF), and should include:
- URLs? to the checked-in versions, using http://svn.zope.org.
- URLs? of the rationale for the changes.
Branched changes are most likely to be merged if they meet the following criteria:
- Rationale policy was followed.
- The patch is minimal for the purpose (no gratuitous diffs!)
- The patch/feature is understandable.
- The patch/feature doesn't break any existing tests.
Policies may vary slightly based on the area of the site.
Tres