Re: Call Monday 24 Jan 2005
Daniel Stone <daniel-rLtY4a/8tF1rovVCs/[email protected]> Wed, 26 Jan 2005 14:05:58 +1100
| Newsgroups | gmane.comp.freedesktop.release-wranglers |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jan 26, 2005 at 12:16:56AM +0100, Roland Mainz wrote: > Adam Jackson wrote: > > I don't see why we should wait until February to discuss something that's an > > issue now. > > It's faster to do the overall planning on the conference. It's much > quicker than doing it on a mailinglist (and it will likely be less > stressing, too :) But, again, not everyone can be there. I suggest not deliberately being exclusionary unless you want to fund everyone on this list who wants to go and participate. > > So if you're the maintainer for xrx, go turn it back on; and then justify > > including it in a monolith when it's a browser plugin, without resorting to > > arguments of the form "but it was in pre-6.7 releases". > > Parts of the xrx technology (like lbx, appgroup, security, Xaw8 etc.) > live in other parts of the monolithic tree. And as Keith Packard said: > There is no other place to put it, the Xorg monolithic tree is the > primary source of this code (excluding the CERN labs version of the > plugin (which is now more or less obsolete as the Xorg foundation now > ships with a working plugin enabled again)). And just splitting off the > source costs time which I don't have right now. Rememeber I only took > maintainership of the xrx stuff as there were several requests to get it > fixed and noone else cared so I did the job after syncing with Egbert. 'I don't have time to do it properly' isn't an excuse for doing it poorly. Your argument here is circular: * we include it because we're the canonical upstream source, * we're the canonical upstream source because we include it. There's no actual reason in this for including a *browser* plugin that could be somewhere else. > > You'll have a much harder time convincing me of the continuing value of old > > rotting source packages (extras/). And please don't make the "but the distro > > might have an old version" argument; that's the distro's bug, not ours. The > > "but the user might not have freetype" argument is also invalid; they should > > go to the freetype website and download the thing then. > > The last argument is VERY valid as it means that there are > prerequirements to build the Xorg tree which can only be fixed by being > an admin of the matching machine (you'll find not many environments > where people grant you root rights without any further explanations). > Installing extra source packages isn't always trivial in some > environemnts and that's one of the reasons why the current way of having > a self-contained build and development environment is still a good > thing. Err, maybe I'm totally missing something, but if you're going to be installing the monolithic tree, surely you have some form of administrative privileges, anyway?! It doesn't make a difference where you install FreeType from if you're going to be slamming 18 million lines of source in anyway. > > Likewise xterm. We don't need xterm for anything - nothing else in the build > > depends on it - and we don't apply any patches to it. > > That is not 100% correct, the Xorg trunk version is AFAIK in sync with > Thomas Dickeys version. ... eventually. There's a while of desync. > > It's the perfect > > example of a modularised application. We have no reason to include or build > > it besides that we always have done so in the past. > > What about those platforms which build&ship Xorg as one chunk (as AIX, > HP-UX do) ? What about them? You haven't provided any arguments here, apart from 'change is bad'. > And what about the old behaiour to build everything for > developers that they can do testing ? Again, what about it? And how is this actually beneficial? If I change something in the server, it's much, much quicker for me with the modular tree. I can do a complete clean and rebuild of the debrix core in 20 minutes on my laptop, whereas the monolithic tree takes a handy two hours. Besides, building individual components allows you to see the impact of your changes: how well it plays with anything else. If anything, it encourages better development. But if you want to rebuild the entire tree, you can do that too. _______________________________________________ release-wranglers mailing list release-wranglers-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org http://lists.freedesktop.org/mailman/listinfo/release-wranglers
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB9wkWRkzMgPKxYGwRAj7MAJ9KlmvK78RoIyUz46ID92Mk87AySACdExOV jnyQuZuxmZ2utA6LG/aorO0= =1tf/ -----END PGP SIGNATURE-----