Development plan -- time to move forward

[Kevin E Martin]

The discussion has significantly died down recently and I think this is
a very good sign that we are reaching consensus and we should begin the
implementation phase.

I've reviewed all of the threads here and in IRC and have incorporated
the comments into the associated wiki pages.  Here are the links:

http://wiki.x.org/wiki/ModularizationProposal
http://wiki.x.org/wiki/ModularizationDevelPlan
http://wiki.x.org/wiki/ModuleComponentList
http://wiki.x.org/wiki/ModularDevelopersGuide

Three questions remain from the discussions:

1. Where should we put xc/nls, xc/include/bitmaps and the xkb config
   files?

   Proposed answer: xc/nls and xc/include/bitmaps are data files that
   are should be included in the lib/X11 component.  The nls files are
   used by Xlib and there is precedence for including nls in X11 from
   the xlibs modularization effort.  The bitmaps are commonly used by
   clients that otherwise depend on no other X library, so by including
   them in lib/X11, we reduce the number of dependencies by one for
   those clients.  The xkb config files should be included with xkbcomp,
   which is where they are currently found in the monolithic tree.

2. Are there additional minimum requirements for builders and developers
   other than those listed in the developer's guide?

   Proposed answer: The primary reason for documenting the requirements
   at this stage is to make sure that everyone understands which tools
   are required for modularization.  Those tools are explicitly listed
   in the required tools section, and this list is sufficient for us to
   begin implementation.  Other minimum requirements will be documented
   as we determine them (e.g., exactly which C/C++ compilers are needed,
   the subset of POSIX/UNIX API's we can assume, etc.).  It is expected
   that the majority of these requirements will be the same as they are
   in the monolithic tree.

3. Should we use AM_CONFIG_HEADER() in the initial release or wait until
   afterwards?

   Proposed answer: If the AM_CONFIG_HEADER([config.h]) macro is used,
   then we will be required to add "#include <config.h>" to the source
   files.  Since we are sharing the source code between the modular and
   monolithic trees for the 6.9/7.0 release, then those changes will
   also appear in the monolithic release, where they do no harm, but are
   not needed.  However, if we do not use this macro, then the changes
   to the shared source code will be significantly reduced.  Therefore,
   we should not use the AM_CONFIG_HEADER() macro in the initial
   release.  Note that once the initial modular release has shipped, we
   can easily add the macro and associated source changes to only the
   modular tree.

If the proposed answers to the questions above are acceptable, then I
propose that we move forward with the implementation next week.

Please review the updated documents (see links above) this weekend or
early next week, and if you have any objections, please speak up now.

Thanks,
Kevin