Kevin E. Martin
We need to find out who will be working on modularization so that we can get an idea of the platform coverage. For the 6.8 release, I created a wiki page for the platforms that we wanted to test, and I would like to do the same for modularization. Below is the list of those platforms that people signed up to test from the previous release and the current one:
Other platforms that were listed, but didn't have anyone signed up to test were:
Ideally, we would like to see at least one person and preferably more signed up to work on each of these platforms; however, it is more likely that we will get fairly good coverage on a subset of them. I expect good coverage on Linux, but we need much more than that. So, if you are interested in working on a platform and have the hardware available, please speak up now so that we can get an idea of where we stand.
The Architecture Working group has given their approval, and we are now in the process of working out the development plan described here. Once we answer the remaining questions (see below) and agree to the plan outlined here, we can begin work.
There are two parts to this project: dividing the tree into separate modules, and then autotooling those modules. These are described in the next two sections below.
Here are the steps that for creating the modules:
Steps #2 and #3 should fall directly out of #1. The directory hierarchy can be filled in as modules are created in the dependency order (see below). Another developer has already started working on #4.
We have a few people that have worked on previous autotooling efforts and many more that have not. Based on feedback from those previous efforts, much of the work will become routine once everyone understands exactly what needs to be done and how to do it. The question is how to fill this knowledge gap so that everyone can be productive initially (i.e., how do we bootstrap ourselves).
My initial thought is that we should learn from the past efforts by having those involved explain the autotooling process that they used. We can then discuss it here on the list, make suggestions and come to consensus on how we want to proceed for our project. By discussing it openly, I think that many more developers will be able to become involved at an earlier stage since they will understand what is involved and how to make it happen. Also, this discussion will form the basis for part of the guide described in the proposal (see documents section below for more info).
What I have in mind here is a simple brain dump of the process used to autotool in the xapps, xlibs, xserver and Debrix projects. I'd also like to see us discuss any common conventions that everyone should follow so that we have a consistent build system and config options name space.
I expect as more people become involved in the modularization effort, the information here will be written and included in the developer's guide.
Note that while there are some dependencies that we need to follow for certain modules to work (lib, xserver, driver), others can be developed independently by using the monolithic tree for bootstrapping (app, font, doc, util). Here's the dependencies:
In order for bootstrapping to work, we need to have the capability to install and use missing pieces from a monolithic build. However, many libraries in the monolithic tree do not have pkg-config metadata files, which will make this difficult. Therefore, we recommend creating the modules in the dependency order listed above.
In the Modularization Proposal, we committed to create the following documents:
Note that in the proposal, this guide was called the "Transition Guide", but it should have been called the a "Developer's Guide" instead since that is a better description of the doc. Using "transition" implies that the guide is only useful during the transition period, which does not reflect the life of this document. This doc is the place where new developers go to find out how to use and develop within the modular tree and will be kept up to date with the latest information.
The initial outline for the developer's guide has been written. During development, we can fill in any new or missing information. To enable it to be easily updated, the developer's guide was placed in the wiki (see link above).
Ideally, we should be able to build the exact same binaries and install them in the exact same place from either the monolithic and modular trees on the same system, but in reality the compiler options will probably differ and produce slightly different code.
The next best solution would be to run through the same set of tests on both installed trees. The testing procedure used in for the 6.8 release is a good starting point for the set of tests used for the combined 6.9/7.0 release. These test should be updated to use the latest X Test Suite available (see the Test Working Group's wiki page for more info). Here's a link describing the procedure:
In addition, we should make sure that the installed trees look very similar and provide reasons for any discrepancies.
Other success criteria would be the coverage we get on the platforms we support in the initial release. As noted above, Linux will most likely be the best supported, but we need others to make this a successful project. I agree with ajax that we should support at least Linux, Solaris, one of the BSDs, Darwin and Cygwin initially since we have active participation by people working on these platforms. However, my hope is that we will have several others supported as well.
None at this time.