[ANNOUNCE] x-jhbuild 0.2

[Dirk Wallenstein]

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