4 ms·

> Intel customers who use Ubuntu will not see any regressions as we will simply continue to support XMir in the Intel driver as part of Ubuntu. This is an issu

> Intel customers who use Ubuntu will not see any regressions as we will simply continue to support XMir in the Intel driver as part of Ubuntu. This is an issue only if you wish to use XMir outside of Ubuntu. Ubuntu controls their own ecosystem so they can just patch/compile/repackage their distribution as needed, like they do for many other packages (i.e. Mesa, xf86-video-ati, and xf86-video-nouveau). The core issue is that they wanted to push XMir support upstream so that other distros could use XMir. Cryptic messages are making people draw their own conclusions as to what the issue is. > We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream. - The Management [1] > I've said it before, I'll say it again. You will not make your open source project better by pulling another open source project down. - Michael Hall [2] I think we are not seeing the full discussion happen in public light and there is a lot of guess work happening. [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=58a7611 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com... [2] https://plus.google.com/109919666334513536939/posts/QzAyr5fo6r9 https://plus.google.com/109919666334513536939/posts/QzAyr5fo...

marshray 13y ago
Why should Intel accept a patch that's only ever going to be useful for one distro? Wouldn't it be better for everyone if the distro would just manage those patches itself?
ealexhudson 13y ago
In all likelihood, few other distros will be interested in shipping XMir. Pushing upstream is usually a better thing to do because it helps reduce the maintenance burden - you're not maintaining a patchset. Intel's decision is basically saying they don't want any of the burden of helping maintain (X)Mir. Canonical/Ubuntu make a rod for their own back every time they settle on these Ubuntu-only solutions imho.
- WestCoastJustin 13y ago
  I don't really see why Ubuntu is getting bent out of shape about this. Maybe this is just a media/blogger generated grudge. Many very popular open source packages are maintained out of stream before getting pushed upstream. DRBD [1] was a very popular package which, after years of patches, finally got accepted into the kernel. I think there is a burden of proof required before asking someone to maintain your patch set upstream. [1] http://www.drbd.org/ http://www.drbd.org/
  - ealexhudson 13y ago
    I'd say it's understandable in this instance - I sympathise because it was initially accepted, and it's not a large patchset. I suspect if there hadn't been the various tech articles about how Intel were accepting XMir, the patchset could have stayed in (supposition, of course).
  - ajross 13y ago
    I don't think "Ubuntu" is particularly bent out of shape. Obviously as the authors of these patches they're already maintaining them in their tree already. All distros have long lists of local feature patches they maintain. And X.org/Intel aren't particularly concerned either, all they did is say "no". Patches get rejected every day. This is just the community yammering away over a particularly flameworthy fork. It's a proxy war over the "Why did Ubuntu write Mir?" question. The actual path to upstream for the patches is mostly irrelevant.
  - efuquen 13y ago
    I think you're mistaking what is probably largely a political issue for a technical one. The sense I get here is that there is nothing technically wrong with the patch, it's not like Intel went back to Ubuntu and said you have to fix X Y & Z to get this merged. They initially accepted the patch and only after having accepted it on technical grounds they've come back and rejected it because Mir isn't the horse they're backing. If anything I would guess Intel is the one getting bent out of shape here, though I couldn't possibly know for sure due to lack of details.
    - 13y ago

marshray 13y ago

Why should Intel accept a patch that's only ever going to be useful for one distro? Wouldn't it be better for everyone if the distro would just manage those patches itself?

ealexhudson 13y ago

In all likelihood, few other distros will be interested in shipping XMir. Pushing upstream is usually a better thing to do because it helps reduce the maintenance burden - you're not maintaining a patchset. Intel's decision is basically saying they don't want any of the burden of helping maintain (X)Mir. Canonical/Ubuntu make a rod for their own back every time they settle on these Ubuntu-only solutions imho.

WestCoastJustin 13y ago
I don't really see why Ubuntu is getting bent out of shape about this. Maybe this is just a media/blogger generated grudge. Many very popular open source packages are maintained out of stream before getting pushed upstream. DRBD [1] was a very popular package which, after years of patches, finally got accepted into the kernel. I think there is a burden of proof required before asking someone to maintain your patch set upstream. [1] http://www.drbd.org/ http://www.drbd.org/
- ealexhudson 13y ago
  I'd say it's understandable in this instance - I sympathise because it was initially accepted, and it's not a large patchset. I suspect if there hadn't been the various tech articles about how Intel were accepting XMir, the patchset could have stayed in (supposition, of course).
- ajross 13y ago
  I don't think "Ubuntu" is particularly bent out of shape. Obviously as the authors of these patches they're already maintaining them in their tree already. All distros have long lists of local feature patches they maintain. And X.org/Intel aren't particularly concerned either, all they did is say "no". Patches get rejected every day. This is just the community yammering away over a particularly flameworthy fork. It's a proxy war over the "Why did Ubuntu write Mir?" question. The actual path to upstream for the patches is mostly irrelevant.
- efuquen 13y ago
  I think you're mistaking what is probably largely a political issue for a technical one. The sense I get here is that there is nothing technically wrong with the patch, it's not like Intel went back to Ubuntu and said you have to fix X Y & Z to get this merged. They initially accepted the patch and only after having accepted it on technical grounds they've come back and rejected it because Mir isn't the horse they're backing. If anything I would guess Intel is the one getting bent out of shape here, though I couldn't possibly know for sure due to lack of details.
  - 13y ago