[Members] X.Org Foundation Election Candidates

[Keith Packard]

On Thu, 2006-10-12 at 07:02 -0500, Jeremy C. Reed wrote:
> 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 board is responsible for the fiscal and legal management of the
organization. It can also serve as a court of last resort when an
impasse is reached among technical contributors, as happened with an
Xprint issue a few years ago. I believe that may be the only such
example; by in large the technical contributors can be expected to
manage development issues on their own.

> What are your thoughts on compiler and "make" portability?

As a project, X has always striven for broad language portability,
staying with K&R C far longer than strictly necessary to avoid locking
platforms without full ANSI compilers. I would like to see some care
retained in precisely which 'modern' language features we adopt in the
core code base, bringing in language improvements where they express
consensus among the supported platforms while holding back on features
available only in the most up-to-date environments. It's always a
balancing act.

More relevantly, I would hesitate to insist that any particular new
language feature be required across the entire code base; massive coding
changes of this nature often receive significantly less review than they
need. Instead, I would encourage the adoption of whatever new features
we deem portable in areas of active development; leaving our trail of
decaying code alone to rot in peace.

For our build tools, I think we have a responsibility to continue to use
systems which are as widely portable as our code; while autotools has
some performance issues, it does offer broad portability along with
external maintenance. I would, however, like to see us find a way to
limit the use of libtool shell scripts during the compilation process;
right now we're spending about half of our build time executing the same
script over and over again.

> What are your thoughts on operating system platform portability?

We should accept reasonable code changes which address issues of
platform portability, and work to ensure that our build tools operate on
platforms which have community members actively supporting them. I would
like to see us regularly testing release candidates on a wide range of
target platforms so that we can quickly identify and repair build
regressions during the release process.

We need to recognize that most developers do use only a single system
and provide mechanisms for repairing accidental damage quickly. I don't
want to see us go too far and require build validation across a huge
number of systems before code can be published though.

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

I use Debian GNU/Linux on x86 and x86-64 systems; I have, in the past,
used X on a rather wide range of hardware and operating systems.

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

For the next year, I'm focusing on improving our ability to adapt to
dynamic hardware environments; we're making steady progress in this area
and should have the largest issues resolved in time for the 7.3 release.

Of course, I continue to work on improving our rendering system and will
be spending some time trying to address performance deficits in
polygon-intensive applications.

Aside from the purely technical issues, I would like to see X.org more
heavily engaged in helping the X community work together. We remain a
geographically disparate group and need help coming together to meet and
collaborate. We should arrange and help fund small technical meetings
around the world that will serve to catalyze developer interest and
allow the project to progress more rapidly.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://foundation.x.org/pipermail/members/attachments/20061013/b589c52e/attachment-0002.pgp