Status of xserver/debrix/modular tree?

[Bernardo Innocenti]

Daniel Stone wrote:
> On Thu, Feb 10, 2005 at 03:32:44AM +0100, Bernardo Innocenti wrote:
> 
>>So Debrix isn't the successor of the xserver/kdrive repository?
>>Are these projects intended to live together?  Wouldn't this
>>require much more maintenance work?
> 
> They are entirely different projects with entierly different purposes.
> Debrix was once a subproject of xserver (separate from kdrive), but
> now it's grown up, moved out of home, is paying its own rent and bills,
> and has nothing to do with xserver.

I see there are no drivers in Debrix's copy of xorg.
Is there another repository or should one use
preinstalled drivers from the regular xorg tree?

By the way, my build failed because of missing drm.h
in hw/xorg/os-support/.  I copied it over from Xorg.


>>I've been reading the xorg list for quite some time, but
>>never spotted any such posting.  Except for occasional
>>announcements of release candidates.
> 
> You missed the XRX + xterm debate, which included a debate about the
> future of the monolithic tree?

No, actually I had read that one... That's where I've read that
the xapps/ and xlibs/ repositories were unofficial and mostly
abandoned.  IIRC, that thread ended without a clear decision.


>  How about 'xc/programs considered harmful'?

I had read this one too, but there wasn't a final decision
after the discussion.

And, yes, I agree with you that the monolithic tree should be
made lighter by moving pieces away from it.


> There are about three other huge discussions that are hugely
> relevant to the stuff you're complaining about that apparently
> hasn't been at all talked about that I can think of.

Sorry, several months have passed since the threads you
mentioned and I still see Xorg not taking any of the routes
that were proposed.

Development proceeds in multiple directions without a
particular focus on a common goal and this, IMHO, is a
wasteful use of the available resources.


>>The point is, for a project as large as Xorg (larger than
>>both the Linux kernel and all of GCC), there's amazingly
>>little traffic on technical mailing-lists.
> 
> Yes, and have you ever considered that maybe that has something to do
> with the amount of people that contribute to the kernel and/or find it
> 'sexy', as opposed to the amount of people that do the same for X.Org?
> 
> I repeat: X is undermanned.

I clearly see this.  What I can hardly understand is WHY.

One may say that hackers are more attracted to kernels
and development tools than windowing systems, but then
why are Gnome and KDE so vital?


>>For example, the new dll loader is a considerable
>>feature which suddenly appeared without a word being
>>said on mailing-list.
> 
> The libdl-based loader (it does not load DLLs) has been in the CVS tree
> for around six years; maybe more.  I think it's been there ever since
> the MetroLink loader was introduced, anyway.
> 
> The only change -- and it was a tiny change, given it was like one line
> in a config file -- was to use it by default.  Some distributions have
> already done this.

I see... I remember when XFree86 4.0 introduced the custom
archive loader.  The original goal was to abstract drivers
from the underlaying OS and bus.  This way, the same binary
driver would be portable to any system with the same CPU.

In practice, existing binary drivers never were made
portable enough, and sharing open-source drivers between
two OSes is useless.  I'm glad to kiss goodbye to the
old self-made elf loader.


>>I was expecting this situation was going to gradually
>>improve with time, but things still seem the same after
>>one year.  Nobody was even discussing about this, so
>>I finally decided to throw my 2 cents :-)
> 
> And, again, this is X being undermanned.  Everyone is busy coding
> instead of blowing hot air on lists or whatever.

Coding and coding in different directions without
a common goal is a very inefficient use of time.

Discussions about high-level issues such as the
development model and long-term plans may cost much time,
but are badly needed in any large scale project.


>>On the positive side, there have been two high-quality
>>releases in just one year.  There seems to be a clear
>>criteria for making a new release and it works fine.
> 
> Yes.  So, clearly, the current system of developer
> communication is not inherently broken.

I think Xorg has a good procedure for guiding releases
and good release managers.  Handling of bugs, patches
and code reviews is also quite good.

What's mostly missing is a long-term development plan
and general consensus on it.  Don't you agree?


>>Every successful project does.  Either informal, such
>>as in Linux, or extremely formal (like GCC's steering
>>comitee), someone needs to set a strategy, some rules
>>and conventions, deadlines...
> 
> For X.Org, this is the release manager, and ostensibly the Architecture
> Board.  In practice, the release manager tends to rubber-stamp the
> consensus of developers on the lists and conference calls, and the
> Architecture Board has not decided on anything in months.  Things happen
> by consensus.

Hmmm... I clearly remember reading the initial Xorg announcements
from Keith Packard.  Keith had shown lots of promisign technology
and set a general direction...

I'll try to summarize what I remember (my free interpretation):

 - Modularize the tree, replacing imake with autoconf/automake;

 - Move away from XAA and redesign driver acceleration around DRI;

 - Switch to a MacOSX-like composite rendering model;

 - Replace the X core graphics with something along the lines
   of Render;

 - Provide a high-level vector graphics API for modern
   applications (Cairo);


This plan came with nice screenshots of alpha blended windows
that made many Slashdot readers quite excited :-)

All these projects were already half-finished in CVS by the time
Xorg was born.

One year has passed and none of these projects is deliverable
or even made substantial progress, with the notable exception
of Cairo.

This is not just because of lack of man-power: the focus seems to
have slowly shifted from the original goals to merely maintaining
the monolithic tree while at the same time a few developers grow
their own X server projects in isolation.

I'm looking forward to see all development stop on xorg/xc and
everybody contributing to a new X server (thus fixing the
"Composite is slow" bug ;-)


>>http://gcc.gnu.org/ml/gcc/2005-02/msg00079.html
>>http://gcc.gnu.org/ml/gcc/2004-10/msg01005.html
> 
> You do know that we have a release manager, right?  Roland Mainz is the
> 6.8.2 release manager.  Who will release-manage 7.0 is as yet undecided.

XOrg's release managers really manage maintenance releases
of the monolithic trees.  As I said, they do a good job by
providing high-quality stable releases.

GCC has a notion of stable branches and mainline development.
Mark Mitchell usually leads the upcoming release from mainline.
Stable branches may have different release managers.

Over two years ago, a long-lived branch called "tree-ssa" was
stated in GCC's CVS repository by a group of developers to
replace the internal representation with one more suitable
for modern optimizers.

The developers pushing for this change tried to reach consensus
by writing papers and specifications to show the benefits of
the new infrastructure.

One year ago, the tree-ssa developers asked the Steering Comitee
for permission to merge back the tree-ssa branch into mainline.
Mark Mitchell announced a set of quality requirements for merging
all patches in an orderly fashion.

The merger took about two months, with occasional status updates
to keep everybody informed.  Of course GCC became quite unstable
during the process, as was expected.

This is probably the single largest infrastructure change
that ever happened in GCC, and it's soon going to be
released officially.


>>Both are interesting readings, with longish threads of
>>developers discussing the decisions of the RM.
> 
> Er, if you want 'longish threads of developers discussing the decisions
> of the RM', look no further than xorg at .  There's lots of 

:-)

> But, as I said, the release manager largely tends to just rubber-stamp
> existing consensus.

There seems to be little consensus on the future direction
of Xorg... forgive me if I'm wrong, that's the impression
I get from watching the traffic on the mailing-list and CVS.


>>In Xorg, maintainership would be easy to assign on a
>>per-library and per-application basis.
> 
> You do know this has already been done, right?

I didn't.  Where is this information available?


>>I omitted talking about code reviews because Xorg seem
>>to be already doing them in Bugzilla.
> 
> We already do code review, but the problem with this is two-fold.
> 
> Firstly, if you're raising the barrier to entry any further (the
> *perceived* barrier to entry is already staggeringly high, not to
> mention the dual penalty of having a massive tree built by imake),
> it had better be worthwhile, and the value of this is unclear.

The Xorg project as a whole appears to be much easier to approach
than the Linux kernel (technially) and GCC (politically).

The code I've seen is quite readable and understandable...
No intricate locking and fancy data structures as in the
Linux kernel... no complex algorithms and abstractions as
in GCC.


> I say that the value of a certain coding style for new code is
> unclear because new code always intrudes to some degree on existing
> code.  Which means that you'll end up with an ugly mish-mash.

Breaking the project into smaller pieces would create an
opportunity for setting coding conventions at least on a
per-module basis...

Cleaning up the mess of preprocessor macros would also
become easier.

I also see massive code duplication or legacy code in
several places.  This is to be expected in a 20-years
old code base, but removing this cruft would make things
better for the future.

The GCC people have also become extraordinarly clever in
refactoring their own code continuously in order to
improve overall quality.

These would be good janitorial projects for newbies like
me, but polishing Xorg this way is useless until it
remains undecided which tree will live.


>>One difference is that in GCC every developer, including
>>maintainers with blanket write privileges, *must* post
>>their patches to the gcc-patches mailing list before
>>committing to CVS.  For controversial changes, patches
>>are always released for approval or discussion.
> 
> X.Org does not have the critical mass of developers needed to make this
> work.  It would simply slow down the pace of development enough to make
> it unusable, and in practice, most people don't care about goings-on
> outside of their particular subsystem.  There are are a few nomads who
> wander through lots of random X components, but most people just stick
> to their subsystem, the nomads defer to them, and that's it.

Sad, but true... I think people who care about Xorg as a whole
should assume leadership and guide the project toward a common
direction.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/