Contributing to ViewCVS Development

Contributions to ViewCVS are very welcome.

Getting Started

Some basic knowledge about Python and development Tools like diff is required. Best is you start with a fresh snapshot, which you may obtain from the CVS-Repository at SourceForge.

Testing and reporting

Testing usability and the installation process on different platforms is also a valuable contribution. Please report your results back to us developers. But always tell us, which version of ViewCVS you used on which platform.

If you are using the latest current development version please note the date of your latest download or cvs update when reporting.

Does a Certain Coding Style Guide apply?

Maintain whatever style is present in the code being modified. New code can use anything sane (which generally means PEP 8). Greg's only real peeve is if someone writes a function call as: some_func (args) -- that space is Huge Badness. Otherwise... shrug.

Submitting patches

Please use the SourceForge project patch manager to submit your patches. Unified context diffs relative to the latest development version are preferred.

If you have commit access, then you should know what you're doing. Just make changes directly. Subscribing to the developer mailing list is recommended in any case.

Preserving security

Since ViewCVS is used in the internet, security is a major issue. If you need to pass data from the request into an external program, please don't use os.system() or os.popen(). Please use the module lib/popen that comes with ViewCVS instead.

Adding new features

If a new file or module is added, a new line in the installer program viewcvs-install is required.

The library subdirectory contains a module debug, which may useful to make performance tests.

If you need a new configuration option think carefully, into which section it belongs. Try to keep the content of cgi/viewcvs.conf.dist file and the library module lib/config.py in sync.

Hacking on templates

The library module ezt contains a module doc string which describes the directives used in the HTML templates, which can be found in the templates sub directory.

Cutting a release

Also there actually is a script tools/make-release, which creates a release directory, all other steps required to get a ViewCVS release out of the door will be currently executed manually by Greg Stein.

Nevertheless in case he ever wants to retire from this job, it is probably a good idea to write the procedure down here:

1. Add a new subsection to the file website/upgrading.html describing all user visible changes for users of previous releases of ViewCVS.
2. Test, Test, Test! At the time of this writing (0.8-dev) there is no automatic testsuite available. So just run with permuting different viewcvs.conf settings and ... pray.
3. Review any bug reports, that are still marked open.
4. Edit the file lib/viewcvs.py and remove the "-dev" suffix from __version__. The remainder should be of the form X.Y, where X is a positive number and Y is a single digit.
5. commit this changed version of lib/viewcvs.py and than cvs tag VX_Y, where X and Y should be replaced by the release number from above. If a developer is willing to volunteer as a bug fix patch release manager, it is now possible to start here at this point with a feature freezed branch using the command

   cvs tag -b VX_Y_maint

6. go into an empty directory and run the command:

   tools/make-release VX_Y viewcvs-X.Y

   This step requires anonymous CVS access to repository at SourceForge.
7. pack the content of this viewcvs-X.Y directory into a tarball.
8. Upload the created tarball into the download files section of the ViewCVS project at SourceForge.
   Greg:Could you please elaborate this step?
9. Edit the file lib/viewcvs.py again and this time increment the __version__ for the next release cycle, again append the "-dev" to the version and again

   cvs commit -m "new release cycle begins" lib/viewcvs.py.

10. Write an announcement explaining all the cool new features and put it out to:
    • www.freshmeat.net
    • Vaults of Parnassus
    • comp.lang.python
    • Where else? I dunno. Suggestions welcome.