On Sun, Jun 20, 2004 at 01:42:43AM +1000, Daniel Stone wrote: > Fonts and docs are a clear decision: the monolithic tree is the only > provider of these. Despite best intentions (and efforts), most apps are > still only available in the monolithic tree.
As best I can recall, it shouldn't be too much trouble to prepare a hacked up monolithic tree that doesn't build the X servers or libraries. I.e. client, fonts, and docs only. XTerm, at least, should be made independent in any event. I think you were saying that as well. > One example here is the DRI tree (now merged into X.Org), which now has > i915 support. A chipset that hasn't even been released. > If this were the modular tree, I could package it up in half an hour > (if that), and upload it, and wham, we'd be supporting this stuff > before it hit the market. Contrast this with i845 (which I still > regard as a huge personal failure), where we took over a year after > one of the most popular integrated cards came on to the market and > flooded in through Dell and other major cheap-PC makers, to even have > support in experimental. You may wish to consider it evidence of a perverse and cruel God, then, that in reward for your justified pride in getting i915 support into the codebase before the chipset is released, Intel recalls it from the marketplace[1]. My condolences. > However, my enthusiasm for the modular tree is tempered by some parts of > it not existing. Thanks for the most quotable statement of the thread. :) > Thus, my short-term proposal is: > * Libraries: fd.o, from /cvs/xlibs, according to > http://people.debian.org/~daniels/xlibs.html. > * Server: X.Org, built from the monolithic tree. > * Apps: Mix of monolithic and some broken-out apps - gradual > migration towards modular. I think the migration should be driven by the phenomenon of people popping up to actually maintain such projects. I get the feeling a lot of the old SI clients aren't going to get much love at all. (For a few, like xmh, this is not really a loss, and I'd argue that one should be shut off and discarded at the source -- if it hasn't already been.) > If we continue to have a single monolithic 'xorg' source package, we can > keep working from this, while in parallel working upstream on the > modularisation efforts. This provides a good solution to the problem of > slowly-drifting X implementations (the libraries are particularly > worrying), and also alleviates our workload, as we can start merging > some of our hundreds of thousands of lines of patches into the parts > we've modularised. > > This means that we can disable app building one-by-one, get rid of the > fonts, docs, et al, and eventually also the server. > > I am willing to expend significant work on this; indeed, I'm in the > middle of my rejuvinated xlibs work, and am prepared to put in the work > to disable the libs on the server side - all the packaging work that > would be needed to transition to using fd.o xlibs. Sounds reasonable. Do you have plans to co-maintain debrix and xlibs with anyone? [1] http://www.forbes.com/feeds/ap/2004/06/25/ap1434368.html -- G. Branden Robinson | Debian GNU/Linux | Ignorantia judicis est calamitas [EMAIL PROTECTED] | innocentis. http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
