[Members] X.Org Foundation Election Candidates

[Egbert Eich]

Jeremy C. Reed writes:
 > Where is the description and/or responsibilities of the Board of 
 > Directors documented? (Are they responsible for technical goals for X.org 
 > code itself or just management of the project?)

The role of the Board is mainly to run the Foundation legally
and financially. The Foundation receives sponsorships from
different sides and the Board should oversee the distribution
of these funds to foster the progress of the X Window System.

It has not done a good job here in the past - the new Board has
to make this a top priority: we need to grow the community
of contributors in different geographies and help this
group to grow together. Therefore it needs to support people
to meet and cooperate better.

Also the board can act as a mediator or last resort decision
maker if a contention exist which cannot be solved differently.
However the Board should only take on this role when called and
no other solutions seems possible.

The Board is not involved in any aspects of the direction of
the technology in the development project. It's the developers
who drive the project forward. One doesn't obtain any say over
technical directions just because he's elected to the Board.

I know that some Board Members would like to see the board 
maintaining technical oversight. However this is not very
realistic: 
Free software development is a much too dynamic process that
the community would accept this. Development is mostly a self
organizing process.
It would work as long as the Board would follow the ideas
and sentiments of the majority of the contributors. If this
fails people would just pack and take the code somewhere else.

Some Board Members are also invovled in development. Thru their
role in the development community they can influence the direction
of the technology - but this is a role that differs from their
role on the Board. The development community operates much like
a Meritocracy. Opinions of people with experience are mostly
respected.

When the Foundation was formed it was tried to set up some group
that oversees the technical direction of the project: The Architecture
Board. It however was soon realized that such a group - which oddly
was almost identical to the board - did not fit the free software
development model.
In order to obtain a wider participation on architectural issues
it was replaced by the 'Architecture Working Group' which is open
to everybody.
However this model did not work out well either - this group
has not gained much relevance.

 > 
 > > If you have questions of the candidates, you should feel free to ask
 > > them here on the <members at x.org> mailing list.
 > 
 > And for the candidates, please share your thoughts about the following.

The issues you are asking for are technical aspects. I can answer
them as a developer and I can try to influence things as a developer.

I hope this doesn't get us wrapped up in a technical discussion which
should happen on a different list.
 > 
 > What are your thoughts on compiler and "make" portability?

Portability of the X Window System code is certainly relevant.
The fact that the X Window System is the basis of the desktop
on almost all U*ix like systems is to some extend due to the
fact that the code will build on so many systems.
X has always valued portibility very high. 
Make protability should definitely be given with the current
autotooled environment. 
The autotools create Makefiles that are probably more portable
than any hand crafted Makefile (and possibly the ones generated
by Imake).
In theory autotools should ensure the portablitiy of your
build system. In reality this is not always the case for two
reasons:
1. autotools themselve contain components which are highly system
   dependent and are likely to break very easily but receive
   only limited testing. libtool is the prime example of this.
   There are however plans to get rid of libtool.
2. You cannot cover all protability issues by your build
   environment. A lot requires portable coding and constant
   testing.
   Accidental breakages are always possible. In order to be 
   portable to platform Y we need people who continuously 
   test and maintain this portability.
   Today the world is very biased (in respect to OS). This
   puts certain systems at a disadvantage. This is a fact that
   we need to accept and neither the group of developers nor
   X.Org as an organization can change this. The call is
   on people using and developing for 'non-mainstream' OSes
   to become more invovled in the X Window System development.
   Volunteers and reasonable patches are always welcome!

However there is another aspect: We should stay portable by
satisfying certain standards (like for compilers) and avoid
compiler specific extensions if we cannot confine them in
a way that they don't affect others (for example in conditional m
acros or code segments). 
However holding modern systems hostage to ancient platforms by 
requiring acient standards seems to be the wrong thing.
Where to draw the line needs to be discussed.

 > 
 > What are your thoughts on operating system platform portability?
 > 
 > (In other words, do you think the world is one operating system and only 
 > one compiler/build system?)

No, I don't think the world is one OS or one compiler.
Build system is a different thing. It's hard to maintain
two build systems simultaniously. Protibility should play
an importand role in the choice of the build system.
Part of the reason of our switch to autotools was that
we got a very portable build system that we don't have 
to maintain ourselves.
But again, if you see issues: bug reports and fixes are
always welcome.

 > 
 > Not really important for a board member, but I am curious: what 
 > platforms do you use for running X and for developing X?

;-)
Primarily I'm using Linux/x86/x86-64. I'm also testing Linux
on PPC, IA64 and s390(x).
I've just started to build it for Solaris and three falvors of
BSD. Open, Free and Net. 
I've also looked into how to automatically create cross compile
toolchains to do build test for target platforms which are
not available. This however was limited to platforms that
use the GNU binutils/gcc/glibc combo. Unfortunately recent
versions of glibc have proven to be very resitant to creating
cc chains.

 > 
 > What are some improvements you'd like to see in X? Why? And when? (And if 
 > you want to get detailed: and how?)

As I said above: the Board will not be able to control the technical
direction of this project. For more details we should really move this 
to a different list.

Just a brief list:

- Dynamic (re)configuration including better mobile support.
- remove more cruft from the aged driver model: the basic 
  structures of the present model are 10 years old. 
- improve rendering support by utilizing more of todays hardware
  capabilities. 

Cheers,
	Egbert.