[krschultz]

""the course of action they have chosen" refers to working on Mir in the first place rather than contributing to Wayland. If that's the case, can't say I really blame Intel."

I absolutely blame Intel. Whatever you think about Ubuntu's decision to make their own X server, it is childish to not include working patches for purely political reasons. It's not like Ubuntu is asking Intel to do their work for them.

So Canonical got railed for not contributing upstream, and they try to contribute upstream they get everyone blaming them again? That's ridiculous.

[ealexhudson]

Most upstreams will generally accept responsibility for keeping code working - just having it "merged" often means then handling bug reports, testing, etc. If the Intel people don't want to maintain specialized Ubuntu-only environments just to test the Mir codepaths, that's kind of their call.

It probably also didn't help that Canonical employees were using it as a political football to boot other GPU vendors, e.g. https://twitter.com/olliries/status/375704285083738112

It was Canonical's decision to fork, if they have to bear the costs of the fork then so be it.

[krschultz]

The old classic argument around why Linux doesn't have a rigid internal API comes to mind (http://www.kroah.com/log/linux/stable_api_nonsense.html). Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software? If Canonical does the work to make the driver universal, wouldn't the whole community benefit?

I'm not a big fan of letting politics get in the way of engineering, and this smells of the fact that Intel is trying to battle ARM in a proxy war, with FOSS as collateral damage.

[tvon]

> Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software?

This still increases cost on the part of Intel.

[sounds]

XMir support in intel's driver uses a significant amount of separate code. I'm not saying intel's actions are ok, but XMir is not creating anything more universal.

[adamors]

What about the FUD storm about Wayland that Canonnical released? When Mir was announced Canonnical and Shuttleworth basically shat on every Wayland developer. They even edited and/or removed their statements later on, it was so bad.

[barrkel]

When a company starts supporting something in public, it usually ends up amounting to a kind of commitment - such that reneging on the commitment has costs, in reputation if nothing else.

In other words, the cost of this patch is not just this immediate code, but ongoing maintenance and support of further features. Almost certainly the guy who pushed the patch doesn't have permission to enter Intel into this kind of commitment.

[the_mitsuhiko]

> Whatever you think about Ubuntu's decision to make their own X server, it is childish to not include working patches for purely political reasons.

Absolutely not. Projects need to take a strong stance on what to include or not because every piece of code in there needs to be maintained.

[coldtea]

>Projects need to take a strong stance on what to include or not because every piece of code in there needs to be maintained.

In theory maybe.

In actual reality, from the 15+ years I follow Linux/OSS, projects are all to happy to NOT maintain code, let it rot, do tons of incompatible changes in major releases, or even start from scratch whenever they feel like.

[bratsche]

Don't blame Intel. This driver is theirs to maintain, not Canonical's. If every distro wanted to create their own display server then should it be Intel's responsibility to merge in support code for all those display servers and to maintain all that code?

[rdc12]

But the Xmir patches, were not a contributing upstream, in any meaningful sence. It's a we have our own project, here is what you need to make it work, and while your at it can you maintain them too (assumption, based on Canonical culture)

Code dumps (especially when the code is only to support your project(Xmir), rather then improving project(Intel driver) itself) != contributing