On 19 April 2011 16:52, Martin Gräßlin <mgraess...@kde.org> wrote: > Hi Mesa-devs, > > yesterday I published a rant about Mesa breaking KWin and given some > comments on Phoronix Forums it seems like there is the wish for more > communication between our development groups and so I want to start it. Please > note that I am not subscribed to this mailing list, so please keep me in CC (I > might not be able to reply this week at all). It is my wish to never have to > rant about the state of Linux drivers any more and that I never have to see > Mesa breaking KWin again. >
I think there are a couple of points here, some of them already made by others. Note that the following is mostly just how I personally see things, not necessarily what anyone else thinks. First, there's the specific issue your blog post talks about. While I understand the issue, and can sympathize somewhat, I essentially think you're just wrong there. (Yeah, I can be direct too.) It's perhaps unfortunate that this change happened on a minor release, but the basic issues are that blacklisting / whitelisting drivers is just a bad idea, and you can't depend on renderer strings being stable. If you do it anyway, it's going to break, you get to keep all the pieces, and you can't blame the drivers. In the more general case, I think hacking around driver bugs is about the worst way to deal with driver bugs in GL applications. In the best case you're just removing an incentive to fix the bug, but it's more likely you just end up creating fragile code or depending on the bug somehow. IMHO it's better to just direct users to the appropriate bug tracker in those cases. You'll get some flak for that, but it's worth it in the long term. Of course the best way would be to work on fixing the bug in the upstream project, but I realize that may not always be practical. Note that I think distributions have some role to play here as well. I think it's just about as unreasonable to expect driver developers to test with every application as it would be to expect KWin developers to test with every possible hardware / driver combination. (And you can't say "My application is more important." either. You're going to find plenty of users that would gladly have us e.g. completely break KWin to make StarCraft 2 run faster, and viceversa.) Realistically speaking we'll have to depend on users / testers testing with development versions to find bugs before releases. If nobody reports bugs that either means nobody noticed or nobody cares. An important part of what distributions are supposed to do is making sure things work well together, so I don't think it's all that unreasonable to expect them to do that kind of testing and report / fix bugs where appropriate. If it does come to the point of writing hacks (pending a proper fix) it's probably also more appropriate for a distribution to carry those than KWin. Something else. Blogging is all modern and all, but it's really not the most constructive way to make things actually happen. In fact, I could certainly imagine this specific blog post causing some resentment. In general, for specific bugs / regressions, please just create a bug report, preferably with a small test case or even a proposed patch. For more general issues posting to the mailing list or just talking to people in IRC (#dri-devel) tends to work best. If you really consider Mesa your most important upstream, it's probably a good idea to be on the mailing list and IRC anyway, just to be aware of what's going on, even if you end up not reading most of it. Some more random remarks below: > Due to the bugs KWin had hit in Mesa, KDE got a pretty bad Media coverage. > This was something I did not like. The bugs were not in our software. I have > no problems with admitting bugs in my part and I take blame for it, but I > cannot stand being blamed for problems due to 3rd party breakage. So I wrote a I'm afraid that's just reality. There's certainly enough misinformation going around about e.g. Mesa, Wine, CrossOver, and just about everything else as well. "News" sites with less than stellar editorial standards don't exactly help either. > hurts. Now feel free to shoot the messenger of bad news, but sorry it is the > truth that Mesa just broke KWin. I disagree with this, see the first part of my reply. > mind. Given how important KWin is for you as a downstream I am really > surprised to see that you do not do regression tests against KWin. What can we > do to help you there? Making sure the functionality required by KWin is covered by piglit would probably go a long way. If KWin has its own set of automated regression tests that's likely very helpful as well, though likely more so for distributions than for Mesa directly. Mesa (like everyone else?) doesn't exactly have huge amounts of developers / QA staff waiting for something to do, so to make something happen there you'll probably either have to automate it or find some people who care specifically about KWin on Mesa and have them test it on a regular basis. > Please understand that KWin has only three regular developers. We are all > volunteers and are doing development in our spare time. Please understand that > I personally do neither have the time nor the patience to follow the upstream > development. In a perfect world I would do KWin development as my day job and > would have the time to follow the upstream development. In reality I have to This is of course fairly off-topic, but I'd be curious if there's no interest for funding that kind of thing. SUSE for example has historically been a fairly strong KDE supporter. > Anyway even if I were able to follow the upstream development it would not > help much. The combinations of hardware, driver, mesa, kernel and distribution > are way too high that our team can ensure that it does not break. This is I don't doubt development manpower is limited, but don't you have any users / testers interested in testing development releases either? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev