.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/body

   1 The Roundup issue tracker
   2   http://roundup.sourceforge.net/
   3 has been around for a while, and provides a nice, flexible design
   4   http://roundup.sourceforge.net/docs/design.html
   5 What ideas from Roundup are worth incorperating in our setup?
   6
   7 Roundup's great strength is the flexibility of its data model and
   8 range of generic support.  It's very easy to extend.  However, there
   9 is only so far you can go with generic support.  Roundup lacks analogs
  10 to the following Command subclasses (as far as I know):
  11   Diff
  12     Has per-issue logs, but no repository-wide summary
  13   Merge
  14   Commit
  15     No VCS backends, see http://issues.roundup-tracker.org/issue2550547
  16   Import_xml
  17   Serve
  18     Has HTML server, but no remote command-line access
  19 Of course, none of these would be particularly hard to add to Roundup,
  20 with the possible exception of VCS backends, which appears to be
  21 in-progress anyway.  However, I really like the simplicity of
  22   `be init`
  23 and the ability to postpone repository customization until you need
  24 it.  So, can we trim down the BE internals to make BE more extensible
  25 without sacrificing our nice default setup and its tools?  The problem
  26 is, how to the commands do their thing if they don't know what they're
  27 working with?
  28
  29 Say, for example, I want to run `be depend bugA bugB`, but my bugs
  30 don't have blocks or blocked_by link properties.  That could be easily
  31 handled by having each command would have to keep track of which
  32 properties it needed and raise appropriate exceptions.
  33
  34 List, Show, Import_xml, etc. would presumably use templates to define
  35 their output/input formats.
  36
  37 As far as postponed customization goes, it would be easy enough to
  38 duplicate Roundup's schema.py and provide a default schema.py for
  39 bugtracking.  This would improve our current system by keeping all the
  40 configurable bits under version control from the start (equivalent to
  41 setting _versioned_property(require_save=True) for all properties).
  42
  43 Another part of the difference between BE and Roundup seems to be due
  44 to the initial backend selection.  Roundup is built on databases,
  45 which encourages their keyed-Class approach with (property, value)
  46 pairs of predefined types.  They use Classes for everything, down to
  47 status values, etc., while we've built those sorts of things into
  48 _versioned_property()s.
  49 Benefits of Roundup approach:
  50   * easy to configure/alter/retrieve list of allowed values
  51   * no need to hard-code properties or resort to extra_strings
  52   * assigned values are actually links to centralized definitions
  53     - easy updates
  54 Benefits of BE approach:
  55   * single file for all properties
  56     - one read and you're done
  57     - many file systems don't handle 'lots of tiny files' well
  58   * assigned values are actual values, not links to centralized defs.
  59     - easy to merge by hand, no need to look up references.
  60 Since it would be fairly simple to add a merging tool that handled the
  61 reference lookup transparently, we can move to a Roundup-like Class
  62 structure by using our current mapfile implementation to store small
  63 Classes.
  64
  65 Finally, would it be easier to merge these Roundup features into BE,
  66 or merge the BE features into Roundup...
  67