Status of xserver/debrix/modular tree?

[Daniel Stone]

On Thu, Feb 10, 2005 at 03:32:44AM +0100, Bernardo Innocenti wrote:
> Adam Jackson wrote:
> >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?

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.

> >all documented on the mailing list, btw.
> 
> I might have missed it...

Quite hard to miss, honestly.

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

You missed the XRX + xterm debate, which included a debate about the
future of the monolithic tree?  How about 'xc/programs considered
harmful'?  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.

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

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.

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

Really, it is just you not reading hard enough.

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

'All development' has not been moved there, not by a very long way.

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

And, again, this is X being undermanned.  Everyone is busy coding
instead of blowing hot air on lists or whatever.

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

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

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.

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

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.

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

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

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

You do know this has already been done, right?

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

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.

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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20050210/3d4f94e7/attachment.pgp>