| |||||||||||||
Plenty of work aheadPlenty of work aheadPosted Dec 3, 2007 15:35 UTC (Mon) by jond (subscriber, #37669)In reply to: Plenty of work ahead by jwb Parent article: The first ATI r5xx/6xx X11 driver release
Running HEAD seems to me to be a fair way for a developer to ensure that the reporter is willing to invest at least a little bit of time towards diagnosing the problem and not just fire-and-forget bug reporting, which is not really of use to anyone.
(Log in to post comments)
Plenty of work ahead Posted Dec 3, 2007 18:08 UTC (Mon) by jwb (guest, #15467) [Link] Building the tip of mesa and xorg is a major undertaking which is likely to break every package on any given system. Nevermind the minor fact that frequently the tip is in an unbuildable or incompatible state. For my own code, I follow the policy of taking a bug report seriously unless I have reason to believe that it has been fixed in a newer revision. I believe there was a long and thoughtful post on linux-kernel regarding this very issue recently, where the author (a major kernel developer) concluded that it's counterproductive to insist on testing with latest-test-rc-mm.
Plenty of work ahead Posted Dec 3, 2007 19:57 UTC (Mon) by drag (subscriber, #31333) [Link] Stable kernel interfaces be damned. Both the X.org Intel drivers and DRI driver and libraries can be compiled out-of-tree and be usable. I've done that before when trying out different features that are only avialable via cvs. (like texture/memory management features for the 915tex driver). Especially with the DRI libraries. Using LD_PRELOAD tricks it's very possible to change between 3D driver versions while running a single X session. There is almost no need to ever have to overwrite anything provided by your distribution. The whole X server can be compiled seperately from distro-provided stuff if you like. If the CVS breaks everything then just go back to what is provided by your distribution. Worst case is that you have to compile a custom kernel to take advantage of some features because of patches to DRM or AGPGART stuff. Soo... If you actually care about trying out patches and filing usefull bug reports then there is nothing that is stopping you. Especially about 3D drivers. Remember almost all of it, except for the DRM or AGP stuff, is userspace. Not much at all depends in any way on the kernel (unlike your proprietary drivers) your using and you can use different LD tricks and chroots to run any of it like any other application. And remember now that X is now _modular_. The drivers themselves can be compiled seperately from X. If your using a relatively recent version of X you can try out the latest 2D Intel driver by just copying over the existing intel_drv.so file! If your worried about breakage then just keep a backup to copy back. This is a little out of date: http://dri.freedesktop.org/wiki/NormalUserBuild For example a most of the stuff has moved away from CVS to Git, but for the most part it still applies. This tells you how to compile and run latest versions of Mesa libs, and DRI without _EVER_EVEN_BECOMING_ROOT_. Have you never had more then one version of a program or libraries installed on your computer before?! If your using Gutsy and the Intel stuff is crapping out on you then bitch to Ubuntu for shipping something broken. On my Debian Unstable/Testing is is pretty stable, not perfect, but it works well. A freind at work has a X3000 chipset and is using Fedora Core 8 and it runs Compiz pretty well except for the 2D and 3D overlay problem/ugliness.
Plenty of work ahead Posted Dec 3, 2007 19:26 UTC (Mon) by dvdeug (subscriber, #10998) [Link] I've had the feeling with way too many projects that they're more willing to make cute new features rather than actually fixing the bugs that are giving me trouble. File-and-forget bug handling or making unreasonable demands on me just accentuate that feeling. Demanding that I exchange a mostly-working program for a program that may not even compile or work remotely correctly is absurd for anyone who actually has to use the program in question on the system in question. I see the reasoning behind it, but OSS already has a preception, often true, of not worrying about the hard unfun stuff that users need. Stating that you're going to ignore bug reports unless they follow a development version just stress that feeling.
|
|||||||||||||