Home
Upgrading
Contributing
License
Who
|
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 (and in particular which version of Python
you use).
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.
CVS keyword macros like for example $ Id$
are currently not used within the source, because Greg
doesn't like them. If you want to know why, read this
EMail (skip to
the second half).
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:
- Add a new subsection to the file
website/upgrading.html describing all user visible
changes for users of previous releases of ViewCVS.
- Update the
CHANGES file
- Update the
website/index.html file to
refer to the new X.Y files. (there are three links to
update)
- 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.
- Ensure all of the above changes have been committed.
- Test, Test, Test! At the time of this writing (1.0-dev) there
is no automatic testsuite available. So just run with permuting
different
viewcvs.conf settings and ... pray.
- Review any
bug reports, that are still marked open.
cvs tag V X_ 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 V X_ Y_maint
- go into an empty directory and run the command:
tools/make-release V X_Y viewcvs- X.Y
This step requires anonymous CVS access to repository at SourceForge.
- pack the content of this
viewcvs- X.Y directory
into a tarball.
- Upload the created tarball into the download files section of the
ViewCVS project at SourceForge:
scp viewcvs-X.Y.*
USERNAME@viewcvs.sourceforge.net:/home/groups/v/vi/viewcvs/htdocs
- ssh to viewcvs.sourceforge.net, cd to the above
directory, and do a "
cvs update " to
pull down the latest website files.
- ftp to upload.sourceforge.net, cd to the
/incoming directory, and upload the .gz
and the .zip
- go to the Admin pages for the ViewCVS project, and
go to "Edit/Release Files"
- select "Add Release" and fill in the new release
name (X.Y)
- fill in the Change Log section with the relevant
portion from the
CHANGES file and
select the "Preserve my pre-formatted text"
option. (and Submit those changes)
- the files uploaded to upload.sourceforge.net
should appear in the "Add Files To This Release"
section. Select them, and add them.
- For each file: change the processor type to "Any",
select "Source .zip" or "Source .gz" as
appropriate, and hit the Update button. (note: you
need to Update each file separately)
- After about 15-30 minutes, the files will appear
on the Files page of the project.
- Select the "I'm sure" button and hit the "Send
Notice" button.
- Note: if you need to hide a prior release, then go
back to the admin page and follow the links for
editing a release. Change the "Status" drop-down to
"Hidden" and submit the change.
- 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 .
- Write an announcement explaining all the cool new features
and put it out to:
|