Project Management Facilities
for GUS
Useful Facilities for GUS
• CVS
• Bug/Feature Tracking
• Mailing Lists
• Documentation
• Release Management
Less Useful Facilities
• Forum
• Task management
• Customer Support
• Patches
CVS
• Organize top level by releasable
“Packages”
• Organize Packages into “Components”
• Components have standard stuff:
– bin, lib, doc, config, install*, readme.txt,
changes.txt, todo.txt?
CVS Packages - proposal
• GUS
–
–
–
–
–
–
Model
ObjRelP
ObjRelJ
Common
DBAdmin
WebFramework
• Annotator
• Dots
– Build
• Allgenes, PlasmoDB, …
• GeneDB
• DistribJob
CVS Practices
• Checkin frequently with accurate
comments
• Use tagging and branching for branches
• Obviates need for author info in source
file?
• Use CVS browser to see branches
• Checkout into directory with branch
designation
CVS Limitations for GUS
• Doesn’t handle
– Schema changes
– Schema documentation changes
– What else?
• These need to be coordinated by CBIL
CVS on SourceForge
• Provides:
– Ready-to-use CVS server
– primitive CVS browser on web
• Use daily tarball for backup
• Consider using “syncmail” to send mail on
commit
Concerns with SourceForge CVS
• Cannot access CVS server directly
– To rename files or directories must:
• Remove files and add, losing history
• Do this recursively (manually) to rename a directory
• OR… go through a request to SourceForge support!
– This impacts our ability to refactor…
– …risking that our code will become badly structured
• Alternative: CVS server at CBIL
– Ability to fully administer it
– Use cvs.gusdev.org
– Use gCVS freeware CVS browser
Bug/Feature Tracking
• Ideal structure:
– For each Package:
• Bugs
– Component
– Version
• Features
– Component
• Each package has its own admin
– Assigns bugs
– Manually collapses redundant bugs with commenting
SourceForge Tracker Limitations
• Rigid bug/feature tracking system
– Must display irrelevant built-in trackers
– Can never delete any tracker
– Can never delete/rename any
categories/groups
– Cannot use text search against
categories/groups
Bug Tracking on SourceForge
• Place component in category field, eg:
– ObjRelJ
– WebFramework…
• Place package-version in group field:
•
•
•
•
– GUS-3.0.1
– GUS-3.0.2
– Annotator-1.1.2
We can constrain on package, component, version
All packages must share one manager
Manager does bug assignments
Alternative:
– Each package gets dedicated bug tracker
FeatureTracking on SourceForge
• Place component in category field, eg:
– ObjRelJ
– WebFramework…
• Place package in group field:
•
•
•
•
– GUS
– Annotator
We can constrain on package, component
All packages must share one manager
Manager does feature assignments
Alternative:
– Each package gets dedicated bug tracker
Mailing Lists
• One for GusOnSourceForge
• One per Package (GUS, Annotator…)
• Start out private (only developers)
Release Management
• A Release is:
– A tagged “package” in CVS
– Tagged with version: 3.1.1
(major.minor.bugfix)
– Should be tagged only after testing
Reasons for Releasing
• “Release early, release often; the mantra of Open Source
software developers everywhere.” – from
•
•
•
•
•
•
SourceForge
Brings new features to users
Brings the system to a workable milestone
Enforces feature prioritization
Forces early testing
Allows proper bug tracking by version #
Encourages automated testing
Making a Release Available
• Two mechanisms:
– CVS checkout –tag
• Ok for developers
• Requires compilation
– Upload Tarfile to SourceForge’s Release site
• Includes .jar file and other compilations
• Nec. when we offer GUS as a turnkey system
• Helps clarify what releases exist
• How do we access their FTP site through our firewall?
What a SourceForge Release
Includes
• The package
• Release notes
• Changed file
– Concatenation of component’s change file
• http://sourceforge.net/project/showfiles.p
hp?group_id=1111
SourceForge Concerns
• Response time
• Perishable trackers
• Unable to fully administer CVS
• Tracker limitations