DAHDI
-----
Problems:
* Not in mainline kernel
  - Also see my sysfs branches
  - Not comfortable with being a single implementation. 
    Want to make sure openzap and unicall get things right.
* Hotplugging:
  - Arbitrary channel numbers set at registration
  - Original /dev/dahdi/NUM convention cannot be used beyond NUM=249.
    - Skip those numbers?
  - Asterisk assumes spans have consecutive span numbers: 
    http://bugs.digium.com/view.php?id=14877
* Using names instead of numbers
  - What I'm aiming for in my experimental branches
  - There seem to be a number of technical issues in Asterisk:
    - E.g. it relies on channel IDs as unique IDs to remove duplicates.
    - And asterisk-gui currently (ab)uses duplicates.

Release Management
------------------
New features keep coming by. New code we write has its share of bugs.

Goals:
* Good test coverage
* Minimize the time a new feature has to wait until it gets into a release
  - Rationale: Many users will want it anyway. And will patch today's code 
    with it. This patching will introduce new bugs and will get less testing.
* Relatively short and predictable cycle (?).
  Rationale: If feature is "almost readey" at this cycle, it can wait for 
  the next one.

Some alternatives:
* Kernel.org:
  - A cycle of 3 monthes.
  - Begins with a relatively short "merge window" where most of the new
    code is merged (3 weeks or so IIRC)
  - This is followed by a series of RCs.
  - Active maintinance only of one version back.
  - Though some versions get long-term maintinance (e.g.: 2.6.16)
  - Still, most users use kernels from Linux distributions.
  - Linux distributions thus take the burden of long-term support
* Desktop Linux distributions:
  - A cycle of 6 monthes
  - http://fedoraproject.org/wiki/Releases/9/Schedule
    - Different types of "freezes"
      - core libs and components first
      - translations strings and docs last
  - Still a month or so devoted to post-freeze beta testing.
  - Maintinance:
    - Fedora: Version N is maintained until 1 month after version N+2 is released
    - Ubuntu: Standard versions are maintained for 3 release cycles
    - openSUSE: 3 release cycles (of 8 monthes)
    - Mandriva: "2" cycles of fulle updates, "3" cycles of base updates.
      (If you count Mandriva's cycle as 1/2 a year)
    - OpenBSD: http://openbsd.org/security.html states to only support users
      of 4.5 and 4.4 (OpenBSD 4.5 was recently released).

* But are we aiming for an upgrade every year or so?
  - If we are, that procedure has to be very well tested. As in Debian.
  - And even then it will be relatively risky in production.
  - If not, "somebody" will eventually have to take the burdon of long 
    term support. Customers will eventually pay for it.