Tree reorganization (Was: Status of xserver/debrix/modular tree?)

[Daniel Stone]

On Mon, Feb 21, 2005 at 02:23:10AM +0100, Bernardo Innocenti wrote:
> Daniel Stone wrote:
> >None of these are subdirectories; they are top-level directories in
> >various projects.  If you check out 'xserver' from the xserver
> >repository, you get the KDrive-based server; I know debrix could be
> >clarified, and indeed, I believe that all the debrix modules are in
> >/cvs/xserver/.old, or /cvs/xserver/.junk or something.
> >
> >But, in any case, none of these are 'subdirectories' -- they are
> >all top-level modules in their own regard, and should not ever be
> >checked out.  (Unfortunately, I'm writing this offline, so I can't
> >check.)
> 
> Yes, that's right.  I have this bad habit of checking out "." or ""
> just to make sure I've got everything.

'Don't do that, then.'

> >I agree, a top-level Makefile would be very nice for people like the
> >BSDs who feel it is important to be able to very easily bootstrap the
> >modular tree without having to use Python.  But, for most people with
> >fully-installed systems, jhbuild, which uses Python, should more than
> >do the job, although the module listings will need a bit of updating.
> 
> Where are the modules listed in dependency order?  I had to guess
> it myself until I got the list from you.

I think xlibs/build-em has now been updated with this information.

> If some people dislike jhbuild, a shell script would still be better
> than nothing.  Any book about project management recommends setting
> up things so that a single command rebuilds all the system from scratch.

xlibs/build-em.

> This is invaluable for newbies and saves some time to experienced
> developers too.  It's also a prerequisite for running automatic
> regression tests.

xlibs/build-em.  jhbuild.

> >Unfortunately 'one command to build them all' also includes FreeType,
> >zlib, et al, in the 'all' part, and also random applications to test
> >core X functions (if we need to include all these, surely 'renderbench'
> >should be included?).
> 
> I'd really like to see render_bench in xapps/.  We may even define
> the goal of the next Xorg release as "make Render perform as at least
> as good as imlib with render_bench".

'We'?  I'm sorry, but if you're not volunteering to do the work, then
imposing random goals on others is a bit rich.

> >Right, but you don't always want to promote them -- there's a
> >difference between forking for specific code (e.g. the VM example; X
> >could be said to already have this, with the r300, unichrome, GATOS,
> >xterm, et al projects), and forking the entire codebase to go in a
> >fundamentally different direction.  We're not talking about things
> >that can be trivially merged back here, it's about two polar
> >opposites.
> 
> Yes, the modular tree cannot live side by side with the
> monolithic tree.  It would take twice as much resources
> to maintain both them once after major changes such
> as ANSIfication, XCB integration, etc.

(Half of xlibs has been ANSIfied, libX11 has an XCB backend.)

> >Of course they can.  Their compositing managers won't be flawless when
> >they first start development, either.  They can build on the current
> >sub-optimal codebase, and then be ready with arse-kicking utilisations
> >of the current infrastructure, when the infrastructure itself is much
> >improved, mainly in terms of speed.
> 
> But they can only use the new technology for optional eye candy
> like soft shadows and other window-manager related things.
> 
> Most of the UI will still run on top of the legacy graphics
> pipeline until Render/Glitz/Cairo gets mature and fast.

You do realise that one of the reasons running GTK apps under, say,
XFree86 4.3, compared to under KDrive, shows such a massive speed
difference is because it makes such extensive use of Render?

> The GTK guys are considering using Cairo to draw widgets.
> QT has this new Andrew API that can use accelerated primitives
> of modern APIs such as Quartz and GDI+, perhaps also Cairo.

... yes, but what's your point?

> >I believe the Composite code has been working in KDrive for around
> >one and a half years now; wasn't it mid-to-late 2003 that it made it
> >in?
> 
> Yes, but since then things have not improved much, from the perspective
> of a user.  Xserver still is a proof of concept that can't be used
> on a desktop due to missing drivers and extensions.

So what?  Why should it be used on desktops?

> I got it to compile with a few trivial changes, but the DRI/GL
> enabled server hangs my machine shortly after opening an xterm
> window.

Then don't use it.

As I said, it is a development platform.  Doing Composite work there
enables people like toolkit developers to get the latest work as
quickly as it can be done.  My point here is that toolkit developers
have had since 2003 to play with Composite, and if they have held off
doing so, then there's not much we can do about that.

> >These are seriously non-trivial decisions.
> 
> I understand.  Disagreement on the big pitcure or on details heppens
> in all projects.  There won't always be 100% consensus on anything
> when multiple developers are involved.
> 
> Making hard decisions may take some time, but not as long as it's
> taking in Xorg.  Because most thread I've read in this mailing-list
> die when everybody have expressed their opinions and are too tired
> to keep arguing over and over.
> 
> The role of an RM -- or a benevolent dictator such as Linus -- would
> be to encourage polite technical discussion, get the facts (TM), and
> then make a decision that doesn't make too many people unhappy.

I don't know what to say here, because apparently nothing else I've been
saying has been getting through.

> I've read many many posts asking to keep old stuff in Xorg,
> even if it increases the maintenance burden of all developers.
> What I've learned from GCC is that patches that remove old
> code are more valuable in the long term than patches that
> bring in new stuff.

You're preaching to the choir, but this doesn't really apply to drivers.

At the end of the day, our mission is to produce a usable X server.  If
we ship with ati, nv and i810, we have utterly, utterly, utterly failed
in that mission.

> >KAA can be implemented within Xorg, absolutely.  It's just a lot of work
> >that doesn't get you anywhere unless everyone's pulling in the same
> >direction.  Telling an entire mailing list of X developers exactly what
> >has been done in KDrive is pretty pointless, also.
> >
> >For various reasons, as I have already stated, KDrive is not, and I don't
> >believe ever will be, a general-purpose X server.  It is very good at
> >what it is, which is an experimental development platform.
> 
> As you said, X carries an incredible amount of legacy
> code and should be made lighter to ease maintenance,
> provide smaller footprint implementations for embedded
> devices, etc.

... are you volunteering?

Do you know how much work is involved here?

> At this time, we already have two competing projects.
> I don't know whether it would be easier/better to
> import Xorg stuff into Xserver or vice-versa, but
> one of these things must be done.

'Must'.

Look, I'm sorry, but the point I've been making for the last couple
of weeks or whatever now is that X simply does not have enough
contributors.  I'm glad that you have invaluable and extensive
experience in GCC, but coming in here and telling everyone they have to
start rewriting XAA on top of KAA or something when you are not fully
technically informed of the issues is not going to help, or endear
yourself to anyone.  What we need is more contributors pumping out solid
code, not more people pumping out hot air on lists saying 'well what you
really need to do is throw away the DIX because no-one needs that and
rewrite it for some reason'.  There is enough uninformed punditry about
what X needs to do and what it needs to be in Slashdot comments already.

Sorry if this is overly harsh, but just rambling on mailing lists means
nothing at this point.  Contributing solid code does.
-------------- 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/20050221/e7ff457c/attachment.pgp>