On Fri, 24 Jan 2003, Thomas Dodd wrote: >>>I respect the fact that it is up to RedHat to decide whether >>>this bug warrants by itself an XFree86 update for 7.3 and 8.0, >>>but I strongly support that updated XFree86 packages should be >>>released to address this issue (maybe wait until XFree86 4.3.0 >>>is out), given that Dell hardware is de facto common hardware >>>and regular RedHat users expect some support for it. >>> >>> >> >>Well that isn't going to happen for multiple reasons: >> >> >>3) Releasing XFree86 4.3.0 for prior versions of Red Hat Linux >> >> >I wonder about this MIke. Since I'm using you 4.2.99 packages, rebuilt, >on and RHL-8.0 system. And your rebuilt packages are not used by 1000000 users out there with you on the receiving end of bug reports either. If something breaks on your system, you might not ever _use_ the stuff that ends up broken and would never know about it. >I DO understand it can ever be an official, supported release, but what >about an unfficial, unsupported one? If it is unofficial and unsupported, then it is something that I would be doing in my own personal spare time. I would get nothing but end user bitching about whatever doesnt work not working, and I'd also get bug reports regardless, and when I close them as "unsupported" I would get users bitching at me for not supporting it. No thanks. Not only that, it would *encourage* users to use it by making it available, and those users would EXPECT that they would be able to safely upgrade their systems to new Red Hat Linux releases with "supported" XFree86 packages. Therefore, I would have to do all of the work I would have to do to release the stuff officially *anyway*. No thanks. Sorry, but you people just have *NO IDEA* what is involved in rolling an official release of supported software, and what *support* means. What you do in a few hours to futz around and rebuild the RPM for an older release of RHL, and hack into your system, which "just happens to work, or so it seems", has received ZERO quality testing on 100000 systems out there in real world customer environments, where customers DO do all kinds of custom things. >Something only on people.redhat.com? Not a chance. Is someone willing to pay me $50 per hour to do this work in my personal time? If so, then we can talk. I have _zero_ personal interest doing work twice. I've done that stuff already, and people who want to use it can upgrade the OS to the release that has it. I maintain WAY too many XFree86 RPM releases that are so different from each other it makes my head spin. For the incredibly small number of people who want a new release and are too hard headed to upgrade the whole OS, they are free to recompile the X server themselves. If it is "so simple, and it works great", then put up a web page and offer RPM packages for people. Or put up a "HOWTO make XFree86 4.3.0 run on Red Hat Linux 7.1" website. Go nuts. If it is so simple to do, and doesn't break anything or require updating 40 packages, then by all means put up an unofficial site and maintain it. It's all open source, and freely available. The amount of resources to do this in an official Red Hat "supported" way, that has been completely properly beta tested, tested by all major partners, and all other packages that are forced to be upgraded, and then everything QA tested, RHN QA testing to ensure upgrades work properly between releases, then guess what? Bugs are found during these processes. Until those bugs are fixed, NOTHING can be released. Of the 20-50 issues that are likely to be detected and require fixing prior to release, guess who gets to fix them! You got it, you're looking at him. And I have to do that, while I try to get the next XFree86 release ready for the next Red Hat Linux release too. It is just not possible, sorry. I have zero interest in doing it in my personal time. My personal time is filled with doing things that _I_ enjoy. Such as working on _new_ X features, enhancements, or whatever, not reliving the past. Red Hat in general, does not release new releases of software for old OS products barely ever. Our OS's get security updates, and they sometimes get bugfix updates. Enhancement updates, are a rarity, and are very dependant on how much engineer time is available to do them. An XFree86 release takes a *tremendous* amount of effort. In addition to all I've said above, it has to be tested on all architectures in all products *separately*, including Alpha, Itanium, PPC, etc. If there is EVER an XFree86 release update of a new version of X for any Red Hat Linux product, it is a very very very lucky thing, for it just consumes a LOT of engineering and QA resources, and risks regression in a product. One example, is for the most part, 8bit depth doesn't work properly in XFree86 4.2.x. This regression was never found until after products shipped with 4.2.x because nobody out there for the most part _uses_ 4.2.x. That is one example. Users who use RHL 7.1/7.2 who would upgrade to 4.2.x if there were to be an official update, who require 8 bit depth working, would undergo a regression and be upset. I'm sure there are other regressions also likely since X is *huge* and it is impossible for anyone to release new releases without some regressions upstream, and it is impossible for a vendor like Red Hat or anyone else to test it to the point where zero regressions exist. So, the answer is a great big fat "NO". It will not happen, and long winded threads like this merely make me not want to bother even considering doing such an enhancement release even if there might be a chance to do one. >I remember you went to a lot of trouble making specfile options >to allow building on older releases. When a new X release comes out, I try to keep the spec file *compile* under both the Red Hat release that we are currently developing, as well as the Red Hat Linux release that I use on my development build machine(s). I also do some testing with these packages. The fact that it is possible quite often for the specfile to build on multiple releases, possibly requiring upgrading of freetype, or some other packages, doesn't mean it will install or install correctly, and if it does install, does not mean it will work, or work correctly. If it does work, or seems to work, it doesn't mean _everything_ will work. It also doesn't mean the package will INTEGRATE _properly_ with the rest of the OS, GNOME, KDE, other components, etc. >Perhaps a _short_ text file and a replacement spec file, so >RHL-7.3 could get it working? Oh yes! I'd just _love_ more than anything in the world, to maintain *TWO* specfiles for one XFree86 release, no make it 1 per Red Hat Linux release. I'll maintain one for 8.0, for 7.3, 7.2/7.1, why not 7.0 too? If it were _simple_ to do that, and it didn't take 1000 hours of time, then I would already be _doing_ that. My work time is a valuable resource for Red Hat. There are 200+ open bugs in bugzilla that need to be fixed. These are bugs users are experiencing in various RHL releases. Should I spend my work time duplicating work done already for our _current_ release? It is a waste of my time. I should be fixing bugs that existing users are experiencing, and I should be working on future development. My personal time is valuable too. I do things in my personal time that interest me, and that quite often ends up being the things I do during my work time, so I dont always draw a big line between work and play. One thing I don't ever do in my volunteer personal time, is do things for users that make demands on me. No volunteer _ever_ does that. >You know the innards of that spec file, and what would need >changed better than anyone. It would probably only take 15-30 >minutes to write the instructions and change the file. Wrong. It is a full time job maintaining that spec file. I started working at Red Hat on X having never looked at the source code before ever prior to my employment here. It takes some time to get up to snuff on X, and also to get up to snuff on RPM if you're not already into RPM packaging. I had the benefit of already being very good at RPM packaging, and the benefit of having worked with bit-banging video hardware a lot in my past. I have no interest in maintaining a document that has to constantly change every day when I make some specfile change. My spec file changelog is among the greatest documented ones in the entire distribution full of software, and the specfile is very heavily commented. If someone can't figure out what to do from that, some text file will not help them. >If you can't, I guess someone on the list could. Perhaps a >RHL-7.3 user can get XFree86-4.3.0 (when released) in a usable >state added to freshrpms.net. They're more than welcome to do so. They'll also have to maintain their own kernel too, in order to synchronize it with the Red Hat kernel DRM, or else DRI either wont work at all, or wont work properly. >Still some pointers/help from you would be great. I don't mind providing pointers at all. I wont do anything though that involves spending a lot of my time, as I consider it to be a huge waste of time. XFree86.org development of XFree86 is extremely understaffed, and not a lot of external people working on it or developing it. The more time I spend working on _current_ development, the less _current_ XFree86 sucks. Look at it this way. For every hour I spend working on old crap, that is one hour not working on new crap. That is one or more bugs that do not get fixed in NEW releases of Red Hat Linux, and it is one or more patches that do not get done and submitted to XFree86.org. Do you want new Red Hat Linux releases to ship with MORE XFree86 bugs than they could have, because I have divided my already limited time across 3, or more XFree86 package forks for old releases? None of that even counts errata, when an errata has to be done to fix some new security hole introduced in a new X release for example. If I release new X for older releases, woohoo! I now get to release security erratum for 19 architecture/distro-release permutations. I can't wait. >>Many major changes happen in XFree86 each XFree86 release that >>require many libraries such as freetype, fontconfig, and others >>to be upgraded also in order to update a prior OS release to a >>new XFree86 release. The amount of engineering work needed to do >>that, is about 30 times the work _minimum_ of Joe Blow(TM) >>downloading the RPM package and ad-hoc rebuilding it for the >>older OS. Joe Blow doesn't have to test 90000 video cards out >>with the OS on multiple architectures, fix new problems that > >Exactly the reason to have an unsupported form. even a source >only release, or packages on a non Red Hat site like >freshrpms.net. Joe Blow only wants it for his sytem, especially >the i830 users. Anything that _might_ work is better than the >current state. Go nuts. It is open source, and anyone is free to work on it. In fact, if someone does, then that is one more person who will be finding problems and fixing them, and sending me patches, so if someone is up to the task, I welcome them with open arms indeed. They will have to make a serious commitment to the task, and they will see just how much work it is real fast. They'll also possibly be interested in debugging problems, and I'll be glad to show them how to gdb the running X server, which is notoriously um.. "fun" for lack of a better word. But if someone is interested, they're definitely welcome. My only complaint is in people who want want want something and don't want to do any work themselves. Those that want to volunteer however their own time and effort, certainly have my attention. XFree86 development needs more people, and someone maintaining XFree86 RPMs for old releases is bound to get hooked and start getting into X development too. >>for that matter. Also, a XFree86 release comes along with a >>forced kernel upgrade for new DRM modules required for proper DRI >>functionality to work. > >If the proper DRM sources were in the XFree86 SRPM, instead of >the official XFree86 ones, it's a simple build. The XFree86 tree >supports building outside the kernel tree, but is never up to >date. Could is be copied/linked to the XFree86 build root >(/usr/src/redhat/BUILD/XFree86/linux_drm ?) and patched during >the prep stage? No way. That would promote and encourage people to do it, and to have more screwed up custom systems out there than there are already, and then to file all their broken problems in bugzilla for me to waste 10 years troubleshooting to find out their using some whacko customized homebrew build of X and/or kernel. I've thought of making X spec allow building of DRM a few times, but the XFree86 source code's DRM source is always ancient compared to what is in our kernel. Keeping it patched and up to date - considering we dont actually _use_ it in the X sources, is extra work, and is a PITA. I don't mind making X specfile changes that make my life easier, or make someone else's life easier as long as they don't make my life harder in the process. >>I updated Red hat Linux 7.1 from 4.0.3 to 4.1.0 with erratum >>before, and with that update we got very lucky. There was a fair >>number of dependancy requirements that had to be released also >>(Xconfigurator, freetype, etc...), but compatibility was quite > >The X config tools don't need to know anything here. This is for users >that can manage to edit XF86Config by hand, for specific problems. How exactly do you stop users from using it that CANT do that? Nice in theory, but before you know it 15000 people are trying to use it, wondering why 30 new bugs are there, and filing bugs in bugzilla against Xconfigurator or something. Bugs like "I upgraded XFree86 to 4.3.0 in RHL 7.3, as I have a Radeon 9000 and want it to work, but Xconfigurator can't configure it". Not to mention various changes like Xft, Xft2, fontconfig, and much much more, etc.. >>P.S. If about 50 of you volunteer to help out by debugging issues >>reported against XFree86 in bugzilla, and attaching patches, >>perhaps I can work on releasing 4.2.1 for 7.3 before 2004. > >Got a link to the bugs? For what ever reason, my searches don't >work. Then again, XFree86-4.2.99.3-20030115.0 is working great >here :) http://bugzilla.redhat.com/bugzilla - go to the query page and query for XFree86 bugs. Be sure to select all of the bug statuses for open bugs. NEW, ASSIGNED, NEEDINFO, REOPENED. If someone, or someones are interested in fixing bugs, or working on any open bug report issues, I'd be glad to give them pointers. Even if some volunteer(s) are willing to just go through all open XFree86 bug reports, read them through, and try to help diagnose the problem, that would be a big help and time saver. Many bugs get reported that are totally USELESS. People report bugs like "My X no works. It work yesterday, but no works now.: Reproduceable: Didn't try Actual results: X no works Expected results: My X works Additional info: To have X work Or people bitch and complain about their card worked in Red Hat Linux 7.whatever and they upgraded to $newrelease and it doesn't work anymore. "I have a Pentium III and a Dell Monitor, and I upgraded from 7.3 to 8.0 and my video is all messy" then don't put anything else in the report. WHAT VIDEO CARD YOU MORON???? God.. You wouldn't believe how many useless bug reports I get. Then I have to spend LOTS of time trying to DRAG information out of someone, often with them not responding for a week or month in between. I almost _ALWAYS_ need their config file and log file, and often other files or info. Yet, very few people EVER attach this information to the bug reports, so I have to ask for it and wait. It might be a day/week/month for them to attach it, and it might not even be the correct log file or config file, meaning I have to ask again and again, and in some cases hand hold the person extensively to finally get the info out of them. Once I get it, I might need more. My favourite is when I ask someone to attach their log file and config file, and instead of them taking the 3 minutes to do so, they wait 2 weeks then say "I *TOLD* you that the log file shows no errors in it, so it is not useful. The config file is the standard config file the tool generates by default. I haven't edited it at all." ARGH. The existance or lack of errors does not make ANY difference. I need this shit so I know what hardware is in the machine, so I know how the X server sees it, what video modes it accepts/rejects, wether DDC is working or not, what modules are loaded, various memory addresses, the 2D acceleration primitives that are active, wether or not DRI is loaded or not, wether MTRR's are working or not, and 50000 other things. I don't want to ask the user to look for those things, I just want them to attach the damn config file and log file! UGGHHHH... I instead have to ask them 400 times for it and then justify why I want it, blah blah blah. No thanks. I just wont look at the report again ever until the info I asked for IS THERE. So.... If someone is interested in helping dig this information out of bug reporters, based on the types of info I ask people for in other reports, etc. it would save me a _lot_ of time that I waste futzing around in bugzilla, allowing me much much more time for doing actual work on our new X release, and for working on potential erratum. It will also build skills in the people helping out, to be able to fix X problems themselves, and help them to maintain their own X RPMs if they wish to. Any bugzilla triage volunteers? ;o) Seriously, it would be an amazingly huge help. If they get really good at it, perhaps some day they'll end up with a @redhat.com email address too. ;o) Wow, I just realized. Is this mailing list ever therapeutic. Thanks guys. :o) /me grins and climbs back into the code cave to fix CVS X bugs. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat _______________________________________________ xfree86-list mailing list xfree86-list@redhat.com https://listman.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
