Intel and XMir
Intel and XMir
Posted Sep 12, 2013 19:12 UTC (Thu) by hummassa (subscriber, #307)In reply to: Intel and XMir by robclark
Parent article: Intel and XMir
It does look more like a statement from intel management saying that they are immature and don't understand what these "free software" and "community" things are about. There is a lot of *that* going around, unfortunately... :(
Posted Sep 12, 2013 19:44 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (15 responses)
> It does look more like a statement from intel management saying that they are immature and don't understand what these "free software" and "community" things are about. There is a lot of *that* going around, unfortunately... :(
whatev.. it's intel's $$ that pays for most of the devel and (all?) the QA on xf86-video-intel, so it's their decision.
The immaturity I see going around is from the people whining about intel not waiting to pay to maintain an ubuntu specific patch.
Posted Sep 12, 2013 20:08 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
Why Intel, and almost all other hardware vendors always support Windows very well?
Posted Sep 12, 2013 20:13 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (13 responses)
Intel actually *incurred* in cost, by patching to revert the patch. At their own expense and at everyone else's expense. So, yeah, immature and whining. Pff.
Posted Sep 12, 2013 21:19 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (12 responses)
Not BS in the least. I'm sorry if you don't understand sw engineering and QA (or possibly not even looked at the patch), but the patch is adding additional code paths which can only be compiled and tested in a ubuntu environment, thereby incurring additional ongoing maintenance cost.
Sure, just leaving the patch in and letting those codepaths bitrot with no compile testing or runtime testing might not cost anything. But it gains nothing either. And having the patch merged implies it is intel's problem to deal with when the code breaks.
Posted Sep 12, 2013 21:29 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (9 responses)
As some guy already mentioned, additional code path mentions additional chance of bug revelation in driver. Some backend wrapper code is hardly the root cause of bugs after some iterations.
Posted Sep 12, 2013 21:43 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (8 responses)
>As some guy already mentioned, additional code path mentions additional chance of bug revelation in driver. Some backend wrapper code is hardly the root cause of bugs after some iterations.
I don't think that is the issue. xwayland works in a very similar way to xmir (from ddx driver perspective), so any bugs it turns up will be the same.
But the problem is, as code in the driver changes, things on the #ifdef MIR side of the conditional compile might get broken. It is easy to happen, and without having an mir/ubuntu development and test environment, there is no way to catch this. So best to leave maintenance of this patch to people who do (ie. ubuntu/canonical).
As I've mentioned elsewhere, if the ubuntu folks were clever, they would figure out how to have a common API between xmir and xwayland (since really, they are doing basically the same thing), so that the same code paths in the DDX driver would get built/tested in both wayland and mir environments. Then it would be no additional workload for xf86-video-{intel,nouveau,etc} and upstreams would happily carry the patch.
Posted Sep 12, 2013 21:53 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (7 responses)
I believe that Intel does have some Ubuntu infrastructure, otherwise how can they release driver installer for Ubuntu 13.04?
> As I've mentioned elsewhere, if the ubuntu folks were clever, they would figure out how to have a common API between xmir and xwayland (since really, they are doing basically the same thing), so that the same code paths in the DDX driver would get built/tested in both wayland and mir environments. Then it would be no additional workload for xf86-video-{intel,nouveau,etc} and upstreams would happily carry the patch.
Remember that the XMir patch is first accepted by the driver developer then reverted by "the management". Your idea is probably good in technical sense, but it is a political story here.
Posted Sep 12, 2013 22:14 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (6 responses)
I don't have the behind-the-scenes view, so couldn't tell you, but since 13.04 is x11 based, I'd have to guess that it is sufficiently similar to other distros to not cause major extra work on intel's part. It is mainly just a matter of installer/packaging rather than being different code paths that aren't even compiled on other distros.
> Remember that the XMir patch is first accepted by the driver developer then reverted by "the management". Your idea is probably good in technical sense, but it is a political story here.
well, it is often the case that the developers aren't the ones caring about scheduling and budget. Maybe Chris should have checked w/ his boss first before merging the patch.
But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
Posted Sep 12, 2013 22:35 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
Seems like you have major problem with code paths. The fact is that many many software support multiple backend no problem.
> But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
Oh, cool, the fancy "boss" understand the issue of Mir and Wayland better than the driver developer.
>And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
Yes, your god Intel can do whatever no problem
Posted Sep 12, 2013 23:19 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
This statement conveys that you have little to no experience writing, testing, or supporting software, yet you presume to tell others how it should or shouldn't be done.
Which, incidentally, sums up your attitude in this thread. What I find sad is that in doing so, you are engaging in the very behavior that you are ascribing to others. (This is a phenomenon known as "projection", BTW)
Posted Sep 12, 2013 23:55 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
So what kind of experience do you have? Never able to get software working using multiple backends?
> yet you presume to tell others how it should or shouldn't be done.
Posted Sep 13, 2013 0:18 UTC (Fri)
by pizza (subscriber, #46)
[Link]
I have fourteen years worth of cross-platform software development experience. And yes, "cross-platform" includes, but is not limited to, "multiple backends".
Posted Sep 12, 2013 23:58 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (1 responses)
> Seems like you have major problem with code paths. The fact is that many many software support multiple backend no problem.
My point here is that it is codepaths that you cannot even compile test without a different distro setup.
Many successful upstream projects also drop backends which they cannot maintain, fwiw.
>> But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
> Oh, cool, the fancy "boss" understand the issue of Mir and Wayland better than the driver developer.
I have been a professional sw developer long enough to see this sort of scenario play out before. Developer wants to add support for some new OS/environment/whatever, QA lead speaks up and says that it will require X additional manpower per release, and Y additional hw setups to test this, head boss crunches the budget/schedule numbers, and decides that it is not possible.
As a developer, I think "great, I can implement this code in a weekend, let's do it!", but I didn't take into account the long term maintenance/QA cost.
Maybe I am disappointed by this. But the boss is the one taking into account the other factors. I don't have to like the decision. But it certainly doesn't make it some big conspiracy.
>> And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
> Yes, your god Intel can do whatever no problem
I do not work for intel, I am not affiliated with intel, and they are certainly not my god. I *am* a happy user of intel graphics. And I'm appreciative of the massive development and QA effort they put in. Desktop linux graphics would not be where it is if it weren't for this, and I think others should be more appreciative of what intel does for linux.
I'm just trying (perhaps in vain) to bring a voice of reason to this silly fud-fest that ubuntu/canonical has started.
Posted Oct 1, 2013 13:10 UTC (Tue)
by JanC_ (guest, #34940)
[Link]
What if you consider the Canonical employees as part of upstream, as maintainers (both development & QA) for that part of the code? It's not like Linus, the Linux Foundation, or any of the other linux developers have hardware to compile & test all linux architectures, drivers & features for example... Of course, if at some point in time Mir-related problems start to accumulate and nobody fixes them (if it becomes unmaintained), then you should drop support for it.
Posted Sep 13, 2013 10:50 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (1 responses)
> I'm sorry if you don't understand sw engineering and QA (or possibly not even looked at the patch)
and ended it in an slippery slope fallacious attack:
> And having the patch merged implies it is intel's problem to deal with when the code breaks.
I'm sorry, but if there is any truth in between, it's not worth it.
Posted Sep 13, 2013 13:49 UTC (Fri)
by robclark (subscriber, #74945)
[Link]
It doesn't cost intel nothing to maintain and QA the patch. Maybe someone from canonical will send patches after the fact when things break. That doesn't really help for QA'ing releases. And since this is something that intel funds, it is their decision to make.
Intel and XMir
Intel and XMir
Is it because it is cheaper to write Windows drivers?
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
I'm never say that Intel must accept XMir patch in the first place. The problem is that it is reverted by "the management", not by the driver developer. Then you try to reconstruct a technical reason for that. It is history revisionism at best.
Intel and XMir
Intel and XMir
Intel and XMir
My point here is that it is codepaths that you cannot even compile test without a different distro setup.
Many successful upstream projects also drop backends which they cannot maintain, fwiw.Intel and XMir
Intel and XMir