Axd / DGSdev
Something that has started worrying me on DGS development is the very low
truck factor (currently 1). Three major issues that will not help successors: there is a significant lack of proper release management, there is code that is not working but present in the main/trunk/master branch, and there is developer-dependent code. For some reason, SourceForge resources are not well used (bug/feature tracker, wiki). These issues make the project more opaque at risk to drown should this single developer leave DGS for any reason (not that I know of).
Why such worrying? Although I currently cannot contribute with significant code, I do believe I can contribute by pointing out trouble spots. Of course, it's up to the (single) dev to decide the worth of my contribution - it's easy to give comments, more difficult to get rid of bugs and implement new features.
There is no need to rush development on DGS. As a result, there is time to do version management correctly. One PITA is that CVS is being used (SourceForge limitation for the current project).
- dont rush code
- dont install test code on live servers
- give tests plenty of time to ripe. THERE IS NO RUSH ON DGS - remember, this is a time-based server ;-)
- prioritize bug corrections; consider removing a feature entirely and start over from scratch if it is unsatisfactory! Otherwise, code gets more opaque and more difficult to contribute to.
- think of the people following in your footsteps, and those running DGS copies without having a dedicated branch in the official rep. become a part of the whole in time as well as in space.
Why not use SVN (or probably much better:
Git) and install the repository server on Samuraj Data? (Excessive server load, maybe?) Or move to a Git rep on SourceForge? (and
this page is also confusing). GitHub? is also fine. Why not move to the new SF platform, and move to Git?
Random, still-to-classify notes
I have removed CVS issues. There are far better ways to manage sourcecode, so I assume someone will take the decision to step away from CVS.
- version string (DGS_VERSION, QUICK_SUITE_VERSION)
- X.Y.Z
- X increments whenever the database structure changes significantly (eg new tables) (Y is reset)
- Y increments whenever new features are added to the LIVE server (Z is reset)
- Z increments whenever a new set of bug corrections is released
- kept in sync with the current branch (or tag)
- are associated to a tag
- shown on each page (footer, "Dragon Go Server vX.Y.Z"), links to the
NEWS file
- it makes no sense to keep the current X.Y.Z way (
post) if
- "X is never changing"
- "Y will always be zero"
- tags
- should not move... moving tags REMAINS a NO NO, one reason being that it makes life more difficult for the outside world. an exception could be a tag that is associated with the dev server version?
- snapshots should be associated with tags. snapshots have a fixed name, therefore the content is FIXED. Otherwise: CONFUSION!. anyway, anyone interested in installing a DGS server will most probably be able to access the CVS rep via some CVS client.
- individual tags should allow external parties to correctly track DGS development
- consistent naming conventions are needed for tags and branches; tags should be cleaned up (renamed)
- branching
- for each new big feature
- for stable branches
- branches are destroyed when no longer needed
- trunk is stable
- I think that many devs avoid versioning procedures because they are not fluent enough in those. This being said, CVS is hell compared to Git or SVN.
- branching and databases - database migration
- a small decently populated test database should be available that can be cloned a volonte for the benefit of branches
- for the dev server, spit off the user tables from the rest, so users don't need to re-register themselve when the DB is thrown away
- a file 'updates/update.mysql' is updated by branches whenever necessary, rather than drag along several copies of update_from_X_to_Y.mysql files. it can be run when a branch is reintegrated. The file is emptied once the LIVE database has been updated. The file is not removed. Remember to also update INSTALL and the dragon*.sql files (this can e done by logically merging the update file into the dragon*.sql files).
- .cvsignore: files that only exist in particular cases (typically local dev stuff such as Makefile, .project, but also 'temp/', 'userpics/'; known_languages.php and timeadjust.php might be an exception) do not belong here; developers should store local stuff in a separate directory 'local/' (and code should refer to that 'local/' directory) so that those can be versioned locally rather than having to discover that some files are ignored (for some reason)
- image files should be in the repository (favicon, images/, 11,13,17, ...), so they can evolve together with revisions. (maybe they were separated because being binary?)
- feature flags are nice, but branches are better. avoid test code (tournament stuff, rule sets) in LIVE server:
- unneeded opaque code that also might have been refactored to support a feature (that is not used or buggy)
- unneeded structures in the LIVE database
- risk to forget flag tests once a feature is accepted
- this applies for tournaments and rulesets
- specific user requested statistics should be preserved in a subdirectory in the rep; per statistic, a subdirectory holds
- HTML page, containing
- output/results
- links to associated threads
- script(s) (mainly queries and formatting instructions)
- script generates the HTML page
- no need to update should server change for any reason - should the stat be needed in the future, then the script can be reviewed
- get rid of
-
the mailing list if it is not used: use it, or disable it; but don't let it hang loose.
- dead code (such as old tournament code). if you need it, retrieve it from the repository history. see also tournaments.txt!
- specs/doxygen-usage.txt
- developer specific stuff: there should be no developer specific stuff on the trunk
- see for example screen.css
- .cvsignore garbage
- refactor cron jobs
- bugs: status; description; workaround, if any; solved in version;
- clean up code; find a way to test multiple versions without having to hardcode server specific stuff (currently needed to differentiate between live and dev server). the idea is that anyone should be able to clone the DGS rep with dragging hardcoded site information.
- Maybe DGS Wishlist should get an additional section "code management"...
- use SF tools: feature and bug trackers
- improve dev server usage in the dev cycle (see
dev server testing)
Priorities
- remove non-working features (tournaments, chinese ruleset) from code; move them to branches
- remove developer-specific code: a checkout/pull/etc should offer only clean code
- improve the develop/test/release cycles
- remove bugs
- add new ESSENTIAL features
Links