Development plan -- time to move forward

[Kevin E Martin]

On Fri, Apr 22, 2005 at 08:34:39PM -0400, Kevin E Martin wrote:
> 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.

I didn't hear any objections, so I'll let the current arrangement stand.

> 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.

Matthieu raised a concern, which has been addressed with the relicensed
pkg-config tools.  I've updated the web page with this info.

> 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.

I retracted my proposed answer after Jim's comments, so we will add the
#include <config.h> lines to the source files.

One other issue has been raised that we have not resolved:

4. Should we move the clients out of the lib module and back to the app
   module?

   Proposed answer: Originally, all of the clients from xc/programs
   (with the exception of Xserver, which was placed in its own module)
   were added to the app module as top layer components.  We tried to
   make some minimal groupings with other clients or libraries, but this
   led to issues, and I believe the situation will get worse as we move
   forward.  Therefore, I think we should keep the lib module restricted
   to libraries and keep the app module flat so that there are no other
   grouping issues.  Vendors who would like to make their own groupings
   can easily combine various components together into packages.

Once we resolve this issue, I think we can move forward with the module
creation.  Please review this issue and raise any concerns you have by
the end of Thursday.  If there are no objections by that time, we will
move forward with the proposed solution.

Thanks,
Kevin