BIND 10 Y4 Usability Work --- We need to improve the user experience in BIND 10. While ultimately the quality of the underlying software is important, first impressions and day-to-day interactions are both critical in making sure people like the software and enjoy using it. Administrator joy is the goal. 1. First Impressions ---- A lot of "first impression" work is not related to the code. * The web site should be clear, making it easy to figure out what code to download and having obvious links to further notes if people are curious. * Installation from system packages should be available in most cases. These will be via the normal OS vendor when possible, or from ISC in other cases. * Installation from code should work smoothly, including having documentation nearby and clear for any specific setups. * Common tasks should be presented in HOWTO and tutorial fashions. * Common tasks should be easy and "just work". Work about First Impressions ---- 1.1. ISC web site redesign [2d] 1.2. BIND 10 web site redesign [5d] 1.3. Web site maintenance process instigated [2d] 1.4. Document target vendor-packaged OS [1d] 1.5. Engage (remaining) vendors [5d] 1.6. Documentation improvements for installation [5d] 1.7. List common tasks [3d] 1.8. HOWTO for common tasks [10d] 1.9. Improve workflow for common tasks [20d] Open Issues for First Impressions ---- * Breaking BIND 10 into smaller packages. 2. loadzone Improvements ---- We have a loader, but it is not very good. We need to either revamp it heavily or replace it. Work for loadzone ---- 2.1 Retro-fit a requirements document [1d] 2.2 Retro-fit a design document [2d] 2.3 Retro-fit unit tests [3d] 2.4 Lettuce tests [2d] 2.5 Create benchmarks [4d] 2.6 improve loadzone 3. bindctl Improvements ---- "bindctl" is the low-level interface to the BIND 10 system. While it will not be the primary means of working with BIND 10, it will occasionally be used, and it needs to suck less. Work for bindctl ---- 3.1 Retro-fit a requirements document [3d] 3.2 Retro-fit a design document [3d] 3.3 Retro-fit unit tests [5d] 3.4 Retro-fit lettuce tests [5d] 3.5 Bug/minor fixes 3.5.1 Inconsistent parsing [1d] 3.5.2 Ugly output [1d] 3.5.3 Missing information [2d] 3.6 Security improvements 3.6.1 Verify server certificate [2d] 3.6.2 Login rate limits [1d]/[4d] (could be done simply or fancy) 3.7 Offline mode [3d] 3.8 Non-interactive commands [2d] 4. Logging Improvements ---- Our logging system is good, but not perfect. Tweaks can make it nicer. Work for logging Improvements ---- 4.1 Audit logging [3d] 4.2 Python logging improvements [5d] 4.3 BIND 9 logging recommendations [5d] 4.4 Tool to check code for logging correctness [3d] We have some changes with logging based on a telco user of BIND 9 which will be helpful for BIND 10. These are the "BIND 9 logging recommendations". 5. Configuration Improvements ---- Some work needs to be done to our configuration system to finish making it awesome. Work for Configuration Improvements ---- 5.1 2-phase commit [5d] 5.2 Restore previous configuration [5d] 5.3 Way to manage previous configurations [5d] 5.4 Off-line configuration 5.4.1 Design mechanism for off-line configuration [3d] 5.4.2 Library to support off-line configuration [10d] 5.4.3 Update modules to use library [5d] 5.5 Design/philosophy document [3d] 5.6 First-class support for old-style configuration files [4d] 6. Debugging Aids ---- It will be helpful to have some debugging aids. Work for Debugging Aids ---- 6.1 Backtrace tool for automatically getting debug information for reporting failures [5d] 6.2 "bind-showtech", which gathers information useful for bug reports, such as the operating system version, memory available, compiler used, zones available, network setup, and so on [10d] 7. BIND 9 Migration ---- The idea here is to have both BIND 9 and BIND 10 use a generic DNS configuration language, rather than to have BIND 10 understand the BIND 9 format. Work for BIND 9 Migration ---- 7.1 Requirements for DNS configuration language [fuzzy] 7.2 Design of support for DNS configuration language [3d] 7.3 Parser that understands DNS configuration language [5d] 7.4 Support for all configurations [15d] 8. Operational Transparency ---- We need to open up BIND 10 so that we can see the pieces inside. Each component needs to have this done. For example, users may wish to see exactly how long until a given zone checks for a new version, when the last time a give process was re-started was, how many recursive queries are currently in progress, and so on. Work for Operational Transparency ---- 8.1 Document guidelines for all modules [3d] 8.2 Detailed review of all modules [5d] 8.3 Work for boss (history of restarts, ...) [5d] 8.4 Work for auth (which ports are being listened on, ...) [2d] 8.5 Work for cfgmgr (current version, number of variables, ...) [3d] 8.6 Work for resolver (size of cache, queries in process, ...) [5d] 8.7 Work for stats [3d] 8.8 Work for xfrin (zones being transfered, ...) [5d] 8.9 Work for xfrout (zones being transfered with ETA, ...) [5d] 8.10 Work for zonemgr (time until refresh, ...) [3d] 9. Command Tool ---- Based on this document: https://lists.isc.org/pipermail/bind10-dev/2011-January/001818.html Note that a lot of the functionality may not go into the command tool itself, but may be incorporated into the BIND 10 core somehow. Work for BIND 10 Command Tool ---- 9.1 Review PRD [5d] 9.2 Design base command tool [5d] 9.3 Build base command tool [20d] 9.4 DNS authoritative commands [10d] 9.5 DNS master commands [5d] 9.6 DNS slave commands [5d] The Command Tool will probably be packaged as a separate product. Note that this area especially may benefit from a more agile approach. - group of interested people? 10. Miscellaneous Improvements ---- There are tons of other little things which could be added. Work for Miscellaneous Improvements ---- 10.1 Each utility should have its own version, and a consistent way of reporting it. [3d] We will need to implement something like dig, host, named-checkzone, and so on. When? 11. Bug Fixes ---- There are quite a few defects which need to be fixed at some point. Propose that we double the amount of bugs that we fix in each sprint, or perhaps have bug-fix only sprints. Effectively this means lowering our expected output by a given amount (10% if we double the number of bugs, 20% if we say every 5th sprint is a bug-fix sprint, ...). 12. xfrin/xfrout Improvements ---- The current xfrin/xfrout have not really been designed for high-volume setups, and are not tested for this. That work must be done at some point. [Is this usability related or not?] xfrin/xfrout Improvement Work ---- 12.1 Retro-fit a requirements document [4d] 12.2 Retro-fit a design document [4d] 12.3 Retro-fit unit tests [5d] 12.4 Lettuce tests [4d] 12.5 Benchmark design and setup [10d] 12.6 Updates to xfrin [10d] 12.7 Updates to xfrout [5d] 13. msgq Replacement ---- We have a lot of bugs and tasks associated with msgq. We were going to use D-Bus after a review of technology, but hit a snag with that. We need to revisit this, perhaps now is the time? 14. DDNS ---- We have DDNS work to do. This is probably just over 1 sprint. 14.1 DDNS implementation 15. Developer Documentation ---- We need to provide better developer documentation. 15.1 Updated architecture documentation [4d] 15.2 "Getting Started with Hacking BIND 10" [5d] 15.3 libdns++ examples [3d] 15.4 libdns++ tutorial [5d] 15.5 Configuration examples [3d] 15.6 Configuration tutorial [5d] 15.7 Logging examples [2d] 15.8 Logging tutorial [3d] 15.9 Data source examples [5d] 15.10 Data source tutorial [5d] 15.11 Documenting supported standards [20d] 16. Data Source NG work ---- At some point we need to implement the sexy in-memory data source that we outlined in the Amsterdam face to face meeting. We also need to define and build the interactions between data sources. Finally, we need to expand our data sources to include additional SQL-based as well as LDAP, BDB, and NoSQL backends. Is this usability? When do we do it?