On Tue, Jun 29, 2004 at 12:11:29PM -0500, Branden Robinson wrote: > 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. Yep. > > 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. I saw that on Slashdot and laughed bitterly. But at least it's time for us to deploy it to a wider audience before they release it again. :) > > 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.) For sure - we have a policy for our X stuff that includes not importing and running away; if you put your name to something, you're responsible for it. > > 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? Let's cross that bridge when we come to it, I suppose; it would be more fruitful to have that discussion when I have working packages. That said, yes. -- Daniel Stone <daniels@debian.org> Debian: the universal operating system http://www.debian.org
Attachment:
signature.asc
Description: Digital signature