Status of xserver/debrix/modular tree?

[Adam Jackson]

On Wednesday 09 February 2005 21:32, Bernardo Innocenti wrote:
> 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

This only says that there are no drivers based on the xfree86 DDX in Xserver, 
not that Xserver is dead.

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

No, not really, and not really.

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

Technical discussion is proportional to number of developers.  Xorg has very 
few of those, as of yet, relative to #LOC.

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

you're joking, right?  the thread entitled "dlloader is now the default" 
doesn't count?

having been the guy who was responsible for flipping that particular switch, i 
thought i did pretty well with discussing it in the open.  In fact not a 
month went by since i started working on it that it wasn't mentioned in some 
thread or other:

http://lists.freedesktop.org/archives/xorg/2004-July/001355.html
http://lists.freedesktop.org/archives/xorg/2004-July/001768.html
http://lists.freedesktop.org/archives/xorg/2004-July/001875.html
http://lists.freedesktop.org/archives/xorg/2004-August/002480.html
http://lists.freedesktop.org/archives/xorg/2004-September/003481.html
http://lists.freedesktop.org/archives/xorg/2004-October/003649.html
http://lists.freedesktop.org/archives/xorg/2004-November/004246.html
http://lists.freedesktop.org/archives/xorg/2004-December/005451.html
http://lists.freedesktop.org/archives/xorg/2005-January/005679.html
http://lists.freedesktop.org/archives/xorg/2005-February/006049.html

that's six months between starting to work on it, clearly stating my intention 
to make it the default, and enabling it by default.  i don't know how much 
more open you want me to be.

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

the idea in Xorg thus far has been that bugzilla is for bugs and the list is 
for design issues.  it's a pretty good system thus far.

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

this is admittedly true.  also the name is obnoxious.  but doesn't gcc's 
bugzilla give a default owner of gcc-patches@ ?

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

... expect people _have_ been discussing this.  see the recent flamefest about 
disabling built-in xrx/xterm/freetype/etc, wherein it was noticed that our 
architectural review process is crap.

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

thanks!

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

my point was that it's _extremely_ informal at the moment; so low as to be 
considered nonexistant, if you're as cynical as i am.  i don't consider this 
a problem as long as my committing peers have good taste; and thus far, for 
the most part, they do.

other people see the need for stronger management and i see their point.  i'm 
willing to accept whatever management process doesn't interfere with getting 
work done.

but again.  these issues have been raised, practically every month.

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

i do think this is an excellent idea.  we really ought to have a continuous 
release manager, meaning someone should be heading up 7.0 _now_.  and i'm 
even willing to be that guy, if the community would have me.

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

the problem here is that much of the code in X far predates the people working 
on it.  there are in fact large subsystems with no maintainer because the 
code works and the person who wrote it has moved on to other, non-X, things.

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

will be much easier once we're modular, too.  the flipside to this is, the 
applications that come with X that are not the server itself, by and large, 
do not get used.  and most of the libraries have had the bugs shaken out many 
years ago.

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

again, we pretty much do this already, we just don't have the words for it 
that gcc does.

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

i sincerely doubt X will ever have a linus.  we have a keith, but it's not 
quite the same thing.

no offense to keith, of course.

imo people argue about coding style standards when they have nothing better to 
be doing, and X has plenty of better things to be doing right now.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050209/277427eb/attachment.pgp>