Status of xserver/debrix/modular tree?

[Bernardo Innocenti]

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

That happened just *after* the dlloader was made active, so I
thought someone had been developing it quietly for some time.

Others already told me that the alternative loader had been in
the tree for years, so it seems I was quite confused.


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

Just a misunderstanding, sorry.


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

As far as I understand, Bugzilla is also being used to
review/approve patches from non-core developers.

If so, reviews don't get read by everybody, so new
developers don't get a chance to learn extabilished
conventions.

Another problem is that core developers escape the
reviewing process, leading to lower quality code.

Public reviews are being done both in the Linux Kernel
and in GCC, with very good results.  Xorg does them too,
but the current process looks weaker to me.


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

It's slightly more complex: bugs get a default Cc: to
gcc-bugs@, which only Bug Masters read regularly.

Proposed patches for bugs are usually posted to gcc-patches@,
with "PRnnn" tags in the ChangeLog.  Sometimes (but not always),
the Bug Masters notice and add a link to the patch in Bugzilla.

When a patch is finally applied to CVS, the loginfo script
automatically appends the changelog entry to bugzilla and
the Bug Masters close the bug.

The weakest point in this process is that sometimes bugs
have patches that nobody has reviewed.  We rely on the
submitter to keep bugging the maintainers until the patch
is approved.

Same thing happens in LKML, but without any record in
Bugzilla.

Some time ago, a GCC developer proposed writing a bot
which finds patches posted to gcc-patches@ and opening
a PR for each one until it gets committed.

The idea was discarded because the required logic
would have been too complex to work reliably in practice.



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

I've re-read the thread now, and all subthreads die
unconclusively.

In GCC's ml, many postings end with "Would this be OK?"
or "I will do foobaz tomorrow unless someone complains".

In order to answer such questions, a project must
designate a group of people who have some kind of
veto-authority.


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

I'm not arguing on the quality of patches committed
to CVS.  There has been very little breakage on xorg/xc/
and the experimental projects only occasionally don't
build.

This is probably because when there are no assigned
responsabilities, people tend to do only obvious and
safe changes.


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

The Linux Kernel has a very informal process, but very
strong authority (Linus and Andrew Morton are good
leaders).

I generally don't believe in steering comitees, but
GCC's seems to work fine, perhaps because most members
of the SC are also very active senior developers.

Debian and Gnome both have democracy with a voting
system.  That may work too, but I don't know these
projects well enough to express an opinion.

The point is: anything is better than pure anarchy.


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

I'm sorry to have stated the obvious...

If I understand correctly, there's already an Architecture
Board composed of senior Xorg developers.  Would the other
developers happily follow their lead?


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

Mark Mitchell used to make a few bad decisions in the
beginning (2.95 -> 3.0, IIRC).

He always was a nice guy who frankly admitted his mistakes
and usually consulted with others before making important
decisions.

With time, he became more experienced and gained stronger
authority.  Now his leadership is very rarely questioned
and he easily manages the available resources to get
things done in schedule.

It takes time to make a good RM, so switching too often
is probably counter-productive.  A newly invested RM
doesn't have enough experience and authority to make
decisions that others will follow.


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

I tend to agree with Daniel on pruning the tree as much as
possible would improve the situation.  Orphaned code should
just disappear from CVS.

Saying "that code does not harm anyone, let's just leave
it alone" is a dangerous strategy.  If someone wants the old
cruft back in the tree, he must show he cares by volunteering
for maintainership.

The GCC project was becoming almost unmainteinable back in
3.0 because nobody cared to drop old targets that nobody
maintained any more.

When someone asked: "Can we get rid of the Vax backend?",
there were always one or two nostalgics who wanted to keep
it in.  They didn't care it increased maintainance costs,
because they weren't maintaining it anyway.

Now GCC has an official procedure to obsolete targets,
and this procedure requires orphaned code to be obsoleted
for a full release-cycle and then kicked out of the tree
if nobody steps forward to revive it.

The Linux kernel has a simpler approach: stuff becomes
broken as a result of day to day work. There's no requirement
for developers to test patches in all supported configurations.

When people notice that some driver is broken, they just
label it "BROKEN" for a while, until someone comes up with
a patch to remove it from the tree.  If someone complains,
he gets offered to maintain the code or just shut up :-)


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

If I was to decide, I'd leave that stuff rotting in an
obsoleted xorg repository until someone finds enough
motivation to create a new subdirectory in xlibs/ or
xapps/.  I bet things such as xmag and xmore would
remain there forever ;-)


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

Very few people are Linus :-)

As an outside observer, I think Keith did quite good PR
for Xorg (and xwin.org before that).  He's generally known
as the man who designed most of the important innovations
in X over the last years.

He's now become much quieter, which is unfortunate because
his PR work was certainly going to attract new developers.
Look how far the DirectFB project has gone with a good
looking web site and continous press releases.  Their code
base is small and their design effort is even smaller, but
I keep finding people who genuinously believe we'll soon
be switching to DirectFB :-)


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

A coding style is just the first logical step to extabilish
a wider set of development rules as in GCC.

Without such rules, people keep arguing about trivial issues
over and over.  Nobody discusses indentation style in LKML
and GCC, because they were published and observed by everybody
since day 1.

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