Axd / DGSdev

Sub-page of Axd

Something that has started worrying me on DGS development is the very low [ext] 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 and offer my SCM experience. 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 (a bit more) correctly.

  • don't rush code (again)
  • don't install test code (using feature flags) on live servers
  • give tests plenty of time to ripe. Again - THERE IS NO NEED TO 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.
  • another reason not to rush is that this is a project with limited resources: expect people to fall in and out, so prepare for the eventuality
[edit]

Issues

This section new stuff plus what I try to fish up and clean from the next section. This page is an attempt to centralise all sorts of perceived shortcomings in DGS development (of which the brunt has been heavily supported by a single dev for several years, see also [ext] this post).

  1. There is a need for a bug tracker. SourceForge offers that for free, but it is not deemed good enough for use. But why reinvent the wheel?
  2. tag naming scheme
    • should be simplified. The current scheme is of the form 1.0.X where X keeps going up! My suspicion is that nobody ever had the balls to question the scheme, and so DGS went stuck into 1.0.
    • Suggestion: X.Y(.Z) (where X is for new features large and small, Y is for bug corrections, and an optional Z for minor stuff).
    • Search also for DGS_VERSION, QUICK_SUITE_VERSION.
    • branch names (other than master) should also be shown on the version label (footer of every DGS page): this confirms to testers what version they really are testing
    • See also
  3. feature voting
    • completely under control of site admin; there's no way to attach comments directly to a feature
[edit]

Random, still-to-classify notes

a later version of this page did not survive the SL crash, so things are a bit messed up here, sorry for that.


  • 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 rep via some VCS 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 was 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).
    • see also [ext] http://www.dragongoserver.net/forum/read.php?forum=4&thread=39593#39789
  • ignore files: 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)
  • 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
    • [ext] 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
      • ignore file garbage
  • issues to deal with
    • translation mappings should be case insensitive
    • user interface has inconsistent use of case
    • translations and FAQ are not available to the outside world. as a result, every server has to re-implement these
  • 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 [ext] dev server testing)
  • use vendor branch management
[edit]

Priorities

To improve code quality:

  1. remove non-working features (chinese ruleset, editor, ...) from code; move them to branches
  2. remove developer- or site-specific code
  3. improve the develop/test/release cycles

Development effort could be classified according to following priorities:

  1. bug correction
  2. features that improve turn based play (without moving DGS towards live play)
  3. features related to rulesets
  4. features that improve playing with more players (tournament, multi player variants, communicating between players...)
  5. features that cannot be implemented in other ways (for which no workarounds exist, such as forums, feature/task/bug lists, ...)
  6. ... (more to add)
[edit]

Links

[edit]

See also

[edit]

DGS vs OGS

For now an obscure, though strongly related addition to this page... Could become a separate subpage, and a full-blown page if there is interest in it. ([ext] https://www.dragongoserver.net/forum/read.php?forum=4&thread=46318#50428)

DGS vs OGS
DGS OGS
x Twitch
x Picture uploading
[edit]

observations


Axd / DGSdev last edited by axd on July 24, 2018 - 11:11
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
RecentChanges
StartingPoints
About
RandomPage
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Goproblems.com
Login / Prefs
Tools
Sensei's Library