Status of xserver/debrix/modular tree?

Wed Feb 9 18:32:44 PST 2005

Adam Jackson wrote:
> On Wednesday 09 February 2005 19:28, Bernardo Innocenti wrote:
> 
>>The Xserver wiki page says the project is dead, pointing
>>users to Debrix.
> 
> 
> i don't know where you're reading that from, Xserver is very much alive.

On Xserver's main wiki page (http://www.freedesktop.org/wiki/Software_2fXserver):

 The X server project holds sources to build an X server
 separately from a full X distribution. The only drivers
 supplied are based on the kdrive framework. Although there
 are configure options for the xorg server, this was an
 aborted effort and the current effort is called [WWW]debrix

(but the link to debrix doesn't work any more).

>>The link to Debrix, however, has 
>>disappeared from FreeDesktop's Software directory and
>>the Arch repository doesn't work any more.
> 
> fdo breakin, debrix arch repo pulled down, hasn't come back up yet.  also not 
> enough people were ready or willing to switch to debrix while we were working 
> on it, and then we all stopped working on it to start working on the 6.8 
> release and never got back to it.

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?

> all documented on the mailing list, btw.

I might have missed it...

>>The modular xlibs and xapps trees seem to receive very
>>little development.  It also looks like they're not
>>being kept in sync with the monolitic tree.  The XCB
>>enabled libX11 would be a nice new feature which already
>>works fine today.
> 
> XCB support is _only_ in the modular libX11.  the modular xlibs have very 
> recently been resynced with monolithic; the monolithic xlibs are going away.

Good!

> scratch that.  the monolith in general is going away.

VERY good!  I like the new autoconf + libtool + pkgconfig
build infrastructure much more than the old Imakefile cruft.

>>I'm curious about the future deriction of these projects?
>>Is there a plan of some kind?  If so, where is it being
>>discussed?
> 
> here, on the list.  check the archives:
> 
> http://lists.freedesktop.org/pipermail/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.

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.

Don't misunderstand me, I appreciate what f.d.o. has done.
What we have now is *much* better than the staleness of
the pre-Xorg era.

>>Unlike other OSS projects such as the Linux Kernel and
>>GCC, there's very little talking in Xorg's mailing-lists:
>>most are just dead, with the exception of xorg which
>>has very little traffic.  Things just seem to "happen"
>>in CVS as if there was private mail exchange between
>>a few developers.
> 
> i subscribed to xorg@ in july 2004.  since then there have been over 4800 
> emails.  that's about 23 per day, on average.  we're no lkml but we're also 
> far from dead.

I'm not merely complaining about the amount of traffic,
rather the lack of relevancy with what's being done in
CVS.

For example, the new dll loader is a considerable
feature which suddenly appeared without a word being
said on mailing-list.

Perhaps it's just me not reading hard enough, but I
also follow Linux and GCC's development and I'm
usually aware of what's being done in these projects.

Big or interesting changes usually cause long threads with
comments and ideas from several people.

>>Reviewing patches in Bugzilla contributes to the lack
>>of communication of this development model.
> 
> i strongly disagree.  bugzilla allows anyone to watch the bugs they care 
> about, and equally, not watch the bugs they don't care about.  this is a 
> feature.  if you really want to see the traffic for all unassigned bugs you 
> can read the xorg-bugzilla-noise archives, and probably even subscribe to 
> that list.
> 
> you don't sound like you've looked very hard for the information you seek.

Hmmm... then I need to get used to this development model.
In Linux, all development happens in the mailing-list.
In GCC, Bugzilla is heavily used to track bugs, but code
reviews and subsequent discussions happen in the gcc-patches
list.

Outsiders wouldn't easily guess they must subscribe to a list
called "xorg-buzilla-noise" to see what's happening :-)

Besides, the list isn't even threaded so it's hard to
understand what's being said.  Tracking bugs with Bugzilla
is a good practice, but moving all development there seems
very confusing...

>>Both Linus Torvalds and Mark Mitchell periodically write
>>status updates of some kind to keep people focused on
>>a common goal.  The KDE and Mozilla projects publish
>>long-term plans.
> 
> Xorg has existed in its current form for barely one year.  the other projects 
> you've mentioned have much longer histories, broader and more active 
> communities, and more developers.  it's not exactly a fair comparison.

Agreed.  When the Xorg project started, my first impression
was that it still lacked many of the extabilished conventions
of other long-lived projects.

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 :-)

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.

>>Never seen anything similar for the Xorg family of
>>projects.  It's not even clear what the management
>>roles are and who is in charge for them.
> 
> you're assuming we have management. ;)

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...

>>I know Xorg is based on volunteer work.  All OSS
>>projects are.  I might have overseen something, but
>>in order to be successful and attract more developers,
>>Xorg appears to need more coordination/PR work.
> 
> what have you done for Xorg recently?

I knew someone would have said that :-)

> i don't mean that as a personal attack, i think your point is valid.  but 
> afaict this is the first post you've ever made to this list.  perhaps this 
> would be an opportunity to start working on some of the things you've 
> mentioned, status reports, roadmaps, and so forth.  apparently no one else 
> has had the time to do so yet (myself included), so this would be a major 
> contribution.

I don't feel experienced enough in project management
and in particular in Xorg's details to do all this
myself.

As a (novice) GCC developer, I'd recommend adopting
*some* of its best-practices.  For instance, they do
have a release manager (RM) who periodically posts
status reports like these:

 http://gcc.gnu.org/ml/gcc/2005-02/msg00079.html
 http://gcc.gnu.org/ml/gcc/2004-10/msg01005.html

Both are interesting readings, with longish threads of
developers discussing the decisions of the RM.

Another important thing is assigning official maintainers
for sub-parts of the project.  In GCC, they tend to have
maintainers for front-ends (languages), middle-end parts
(optimizers) and back-ends (target CPU's or OSes).

In Xorg, maintainership would be easy to assign on a
per-library and per-application basis.

A maintainer should assume responsability and authority
for accepting or rejecting patches to their subsystem.
The RM or a pair of senior developers may overrule his
authority if needed.

GCC also has a 3-stage development cycle that might
be interesting for any large project:

  http://gcc.gnu.org/develop.html

I'd also strongly suggest adopting some kind of coding
standard (not GNU's -- it sucks ;-), at least for new code.
Debating a coding standard can lead to endless flame wars,
so I think it should be imposed once there's someone with
a strong authority (such as Linus).

GCC's trick for keeping quality high is simple: strongly
reject patches from people who didn't follow *all* of
the conventions for coding, testing and submitting
changes.  Instead of ignoring contributors who ignore
the extabilished practices (Linus style), they point
them to published documentation, so even corporate
employees tend to learn very quickly ;-)

I omitted talking about code reviews because Xorg seem
to be already doing them in Bugzilla.

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.

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