Thoughts About Next Steps ========================= Module Selection ---------------- I intend to improve the cohesiveness of a repogroup concerning used modulesets, as well as reduce the effort it takes to formulate test cases. Currently, it's a bit tedious to write and propagate a moduleset for every testcase and/or personal-tree. This can be simplified by offering module selection through the configuration. Please tell me if you spot holes in this plan.
I would like to start with what I think could be a desirable configuration. For the purpose of this example, let's go back in time: http://who-t.blogspot.com/2009/03/xi2-implementation-take-1.html The configuration for it (with some imaginary additions) could look somewhat like this: [modsel.xorg-server] module = whot/xorg-server branch = xi2 deps = -libHello +libWorld (these are plus/minus dep signs) [modsel.libXi] module = whot/libXi branch = xi2 etc. A user would save it as a config-token, check it out, and then work with it. In a later step, and if it turns out to be beneficial, more module specific settings could move into such sections like, autogenargs, makeargs, tag, etc. When a moduleset is being assembled and there are configuration sections like above, the selected modules will replace the main modules specified as the subsection name. Optionally, the dependencies of the main modules will be copied and modified as requested. This is meant to be used when there are branch specific dependencies. The selected example server could look like: <autotools id="whot/xorg-server"> <branch module="~whot/xserver" checkoutdir="people/whot/xorg-server"/> </autotools> The idea is that such modules can be inserted at the corresponding main module location in the dependency graph. You could keep building all of 'xorg' without the need to duplicate all modules that have a dependency on the replaced module. Overall this seems to be feasible with a reasonable amount of work and offers test case descriptions in the form of configurations that are easy to read. I thought about completely deriving a module description from the configuration, but then you would loose the repo again when switching the configuration. Maybe in a step after this one there can be repositories added to a repogroup database from the command line or from the configuration. A Moduleset Stack ----------------- There could be a separately managed stack of modulesets to let the main project-moduleset be augmented and overridden by additional modulesets. This could be modulesets located in the home domain of a developer, so that it is under the control of the corresponding developer, who can quickly set up repos for auditing. Promp & Navigation Improvements: -------------------------------- Because in this scenario all used modulesets are always 'active', and each repository has its own module-id, there could be a repogroup database which caches some properties of modules like name and location. That could be made available to the prompt and navigation. -- Greetings, Dirk _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
