| Prev | Chapter�14.� CVS Guidelines - | Next |
|---|
There are three main ways to contribute code to OpenACS:
To contribute a small fix, if you do not have a developer account, submit a patch.
If you are making many changes, or would like to become a direct contributor, send mail to the Core Team asking for commit rights. You can then commit code directly to the repository:
Use one of the checkout methods described above to get files to your system. This takes the place of steps 1 and 2 in the section called “Installation Option 2: Install from tarball”. Continue setting up the site as described there.
Fix bugs and add features.
+
There are three main ways to contribute code to OpenACS:
To contribute a small fix, if you do not have a developer account, submit a patch.
If you are making many changes, or would like to become a direct contributor, send mail to the Core Team asking for commit rights. You can then commit code directly to the repository:
Use one of the checkout methods described above to get files to your system. This takes the place of steps 1 and 2 in the section called “Installation Option 2: Install from tarball”. Continue setting up the site as described there.
Fix bugs and add features.
Commit that file (or files):
cvs commit -m "what I did and why" filename
Because this occurs in your personal checkout and not an anonymous
one, this commit automagically moves back upstream to the Mother
@@ -23,9 +23,9 @@
new�revision:�1.94;�previous�revision:�1.93
done
cvs�commit:�Rebuilding�administrative�file�database
Although you should add your package on HEAD, you should do package development on the latest release branch that your code is compatible with. So, after completing the import, you may want to branch your package:
cd /var/lib/aolserver/service0/packages/newpackage -cvs tag -b oacs-5-1
See the section called “How to package and release an OpenACS Package”
Some packages are already in cvs at openacs-4/contrib/packages. Starting with OpenACS 5.1, we have a Maturity mechanism in the APM which makes the contrib directory un-necessary. If you are working on a contrib package, you should move it to /packages. This must be done by an OpenACS administrator. On cvs.openacs.org:
cp -r /cvsroot/openacs-4/contrib/packages/package0 /cvsroot/openacs-4/packagesUpdate the modules file as described above.
Remove the directory from cvs in the old location using cvs rm. One approach for file in `find | grep -v CVS`; do rm $file; cvs remove $file; done
See the section called “How to package and release an OpenACS Package”
Some packages are already in cvs at openacs-4/contrib/packages. Starting with OpenACS 5.1, we have a Maturity mechanism in the APM which makes the contrib directory un-necessary. If you are working on a contrib package, you should move it to /packages. This must be done by an OpenACS administrator. On cvs.openacs.org:
cp -r /cvsroot/openacs-4/contrib/packages/package0 /cvsroot/openacs-4/packagesUpdate the modules file as described above.
Remove the directory from cvs in the old location using cvs rm. One approach for file in `find | grep -v CVS`; do rm $file; cvs remove $file; done
CVS commit procedures are governed by TIP (Technical Improvement Proposal) #61: Guidelines for CVS committers @@ -50,9 +50,9 @@ each dot release.
New packages should be created in the
-
+
/packages
-
+
directory
and the maturity flag in the .info file should be zero. This is a change from
previous policy, where new packages went to /contrib/packages)
@@ -135,9 +135,9 @@
flag which defaults to no-effect wouldn't require a TIP. Added a
new mandatory flag to an existing function would require a
TIP.
-
We don't currently have clear standards for committing code.
@@ -171,9 +171,9 @@ applies to all packages. This tag can be used to fork packages as needed, and provides a common ancestor between the fork and the OpenACS code so that patches can be generated. -
Informal guidelines which may be obsolete in places and should be reviewed:
Before committing to cvs you must submit a bug report and