Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
But what is the real problem here? Can you point out any notable contributor of Mir outside Canonical?
And Qt also has a CLA anyway: https://qt-project.org/legal/QtContributionLicenseAgreeme... (check 3.1)
Too many FUDs about Ubuntu these days
Posted Jun 19, 2013 17:09 UTC (Wed) by mjg59 (subscriber, #23239)
Well, that's kind of a self-fulfilling prophecy. Having a CLA means that corporate entities are discouraged from contributing to a project (why would you work on something that a potential competitor can sell into markets that reject copyleft code without you being able to do the same?), and Canonical have done a pretty good job of burning bridges with community developers. Compare to Wayland, which *does* have significant contributions from non-Intel developers.
Posted Jun 19, 2013 17:41 UTC (Wed) by maxiaojun (subscriber, #91482)
Cool, so the vision of free software is that multiple competing for-profit entities contribute to a same project and sell proprietary forks separately?
> Canonical have done a pretty good job of burning bridges with community developers.
Many thanks to FUD spreaders like Martin Gräßlin
Posted Jun 19, 2013 17:48 UTC (Wed) by mjg59 (subscriber, #23239)
Hey, you asked. I'd *prefer* nobody be able to sell proprietary forks. But if only one corporate entity is able to sell proprietary forks, no other corporate entity is likely to contribute.
"Many thanks to FUD spreaders like Martin Gräßlin"
I'd blame it on the complete unwillingness to put any effort into working with upstream communities, personally.
Posted Jun 19, 2013 18:19 UTC (Wed) by maxiaojun (subscriber, #91482)
Probably true, not a big concern for me, though.
> I'd blame it on the complete unwillingness to put any effort into working with upstream communities, personally.
I see this aspect of Canonical is improving. For example an RFC for Mir backend is sent to mesa-dev.
Posted Jun 19, 2013 18:23 UTC (Wed) by mjg59 (subscriber, #23239)
Sure, but it means you can't point at the Mir repository and say "No other corporate entities have made significant contributions to Mir, so the CLA isn't relevant" - it's more likely that cause and effect are the other way around.
Posted Jun 19, 2013 18:31 UTC (Wed) by mgraesslin (subscriber, #78959)
Posted Jun 19, 2013 18:39 UTC (Wed) by jubal (subscriber, #67202)
Posted Jun 19, 2013 18:51 UTC (Wed) by mgraesslin (subscriber, #78959)
Is that a reason to insult me? Is that a reason to say I have an unpleasant personality? Should I just say "yes and hurry" to everything so that everybody is happy?
Posted Jun 19, 2013 18:59 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 19:04 UTC (Wed) by mgraesslin (subscriber, #78959)
Posted Jun 19, 2013 19:24 UTC (Wed) by maxiaojun (subscriber, #91482)
The LWN article is much more gentle and objective.
Posted Jun 19, 2013 19:56 UTC (Wed) by mgraesslin (subscriber, #78959)
Posted Jun 19, 2013 20:07 UTC (Wed) by maxiaojun (subscriber, #91482)
So, naturally, the whole thing looks like FUD, sounds like FUD, and I thought it is FUD.
Posted Jun 19, 2013 20:26 UTC (Wed) by mgraesslin (subscriber, #78959)
Posted Jun 19, 2013 20:32 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 20, 2013 18:02 UTC (Thu) by ovitters (subscriber, #27950)
Posted Jun 19, 2013 19:29 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 20:06 UTC (Wed) by mgraesslin (subscriber, #78959)
The only part which I accept as could have written better is the point about the buggy graphics stack in Ubuntu. I admit that this was an emotional point as we just at that time had seen (again) many crash reports due to breakage in the stack (https://bugs.kde.org/show_bug.cgi?id=314602). As I wrote I can see this in our bug reports and I gave the analysis of that to the Kubuntu developers before I wrote this blog post. And our bug tracker is open - you can look for yourself.
Posted Jun 19, 2013 20:17 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 20:29 UTC (Wed) by maxiaojun (subscriber, #91482)
No fact here, just try to mimic Martin's writing style.
Posted Jun 19, 2013 20:51 UTC (Wed) by mgraesslin (subscriber, #78959)
I cannot understand why you consider this as FUD. If you think it is because I badly phrased this section, I'm sorry: it was not intended. Maybe you are over-interpreting my blog post?
Posted Jun 19, 2013 21:07 UTC (Wed) by maxiaojun (subscriber, #91482)
1. The tone is harsh rather than gentle. (you do read LWN, right?)
2. Some unfounded bold claims are made, e.g., always had worst stack. You've seen a serious bug then you say there is a serious bug. Not need for false generalization.
3. In general, you makes many solvable problems appear unsolvable. This is the key difference between constructive criticism and FUD.
Posted Jun 20, 2013 8:37 UTC (Thu) by ovitters (subscriber, #27950)
Further, something not being not constructive criticism doesn't make it FUD.
Posted Jun 20, 2013 17:24 UTC (Thu) by maxiaojun (subscriber, #91482)
Posted Jun 20, 2013 17:59 UTC (Thu) by ovitters (subscriber, #27950)
Posted Jun 20, 2013 17:37 UTC (Thu) by maxiaojun (subscriber, #91482)
Posted Jun 20, 2013 18:02 UTC (Thu) by maxiaojun (subscriber, #91482)
Posted Jun 20, 2013 18:40 UTC (Thu) by jake (editor, #205)
Posted Jun 20, 2013 11:26 UTC (Thu) by morhippo (subscriber, #334)
Posted Jun 20, 2013 17:34 UTC (Thu) by maxiaojun (subscriber, #91482)
I do contribute elesewhere, in various ways.
Martin's FUD is certainly better than Microsoft's. As so many are confused by such junk post.
Posted Jun 20, 2013 18:01 UTC (Thu) by ovitters (subscriber, #27950)
Posted Jun 20, 2013 18:03 UTC (Thu) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 20:53 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 20, 2013 7:02 UTC (Thu) by mgraesslin (subscriber, #78959)
Posted Jun 25, 2013 18:57 UTC (Tue) by nix (subscriber, #2304)
Posted Jun 19, 2013 19:04 UTC (Wed) by rgmoore (subscriber, #75)
Cool, so the vision of free software is that multiple competing for-profit entities contribute to a same project and sell proprietary forks separately?
I would say that the vision is that many different people and groups will become contributors to the project. That is more likely to happen if all contributors have equal rights to the code, either no right to make proprietary versions (e.g. GPL licensed software without copyright assignment) or everyone has the right (e.g. MIT or Apache licensed software). When one developer sets itself up with special rights to spin off proprietary versions, that discourages commercial competitors from participating, reducing the pool of potential contributors.
Posted Jun 24, 2013 14:18 UTC (Mon) by pboddie (guest, #50784)
And really, bringing out the "FUD" label is like the boy who cried "wolf!", especially given that I noticed the word "silo" used on two occasions in this monster thread, once by someone who was clearly annoyed by the Ubuntu/Canonical strategy, and once by someone who didn't mind. This is especially amusing given that I attended a talk by an Ubuntu representative last year, the content of which indicated that developing software in silos was a bad thing. Maybe that was the speaker's own personal opinion, but I feel that I should have asked a question about that rather than feeling it was rude to bring it up, because I'd really like to know how the modern Ubuntu way of the silo is exempt from this observation.
Posted Jun 19, 2013 17:49 UTC (Wed) by jspaleta (subscriber, #50639)
The dev team for Mir has not done the basics necessary to give externals an on-ramp to work with the sourcecode, even ahead of worrying about signing the CLA. I can't just pull Mir from bzr and test it. I need out-of-tree mesa patches as well at a minimum..and they haven't documented how to pull those from bzr or git as part of their build from source procedure. Why on earth would ANY external bother poking at project sourcecode they can't build up and test from source? That's just crazy.
This lack of information doesn't reach the level of "hostile" .. but it certainly indicative of inexperience actually knowing how to be a viable upstream project, instead of a distribution-specific team.
Posted Jun 19, 2013 17:56 UTC (Wed) by maxiaojun (subscriber, #91482)
Mesa should be an "experienced" upstream, right? But I suspect whether I can successfully build Mesa using information from:
Posted Jun 19, 2013 18:14 UTC (Wed) by jspaleta (subscriber, #50639)
wayland's build instructions for wayland head workforme well enough in multiple linux distribution environments. It includes instructions to pull wayland and mesa from git. Building wayland's tip on a daily basis from source is doable because the build from source instructions are reasonably vendor neutral.
This isn't about whether mir or mesa are hard to build. Mesa builds for me from source frequently enough...barring caveats for bad commits and what not. I know wtf I'm doing with compiles from source. But right now to build and self-consistently test mir with the toy mir clients, mesa oatches are required that have not been committed into the mesa git repository...even as a pre-merge branch. They exist in some bzr branch buried in the guts of launchpad that have not been documented in the mir build from source instructions.
If the mir build from source instructions can point me to an lp bzr branch for mir head... they certainly should be pointing me to a the matching mesa bzr branch that is required. Its an oversight that Canonical led projects make a lot. They don't "think" like vendor-neutral projects when working on "upstream projects" so they never really bother to document how to work with the source code outside of Ubuntu. Its a failing of their approach to "upstream" development generally and its systemic to their corporate culture... nothing personal...but they just don't think about the build from source as a primary way for skilled developers to work with their project...and their thinking is...myopic.
Posted Jun 19, 2013 18:37 UTC (Wed) by maxiaojun (subscriber, #91482)
Mir hasn't got upstream support from Mesa because it started much later than Wayland. Is anything wrong here?
Posted Jun 19, 2013 18:42 UTC (Wed) by jspaleta (subscriber, #50639)
The request for review to the mesa list is not the current required patchset. There is a mesa branch buried somewhere in lp that is required to build and test mir. publish that url as part of the mir build from source instructions so mir development head can be built and tested outside of an Ubuntu environment.
Posted Jun 19, 2013 18:45 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 19:06 UTC (Wed) by jspaleta (subscriber, #50639)
In the meantime feel free to raise this on my behalf and on behalf of every single external developer who needs to work with Canonical projects outside of a well conditionsed Ubuntu environment. Ive already communicated this requirement to a developer involved in mir in this forum and also in private email.
I only bring this up because KDE upstream has specifically stated the lack of multi-distribution mir binaries as one of the reasons they are keeping a hands off approach to mir. And because I really don't want to see Canonical's... decision making... hurt the KDE/Kubuntu relationship more than absolutely necessary I'm standing up and I'm pointing out why mir is basically undigestable right now to any externals. So perhaps, inside the timeline that matters to Kubuntu, we can make mir more palatable to KDE as a technology by making it a buildable and testable as a vendor neutral tech shoved into other distribution repositories or at least packaged.
Now for me personally... viable build from source instructions are a non-negotiable prereq to consider any technology vendor neutral. Canonical teams don't seem to see that as important historically..and that's a shame really...its such a very small thing to do...document which frelling lp branches to pull to chew on the project head including patched dependencies. And the more I think about how trivial it actually is considering how easy the lp infrastructure makes this.. the madder I get about how this is consistently overlooked by Canonical projects as step-zero in on-ramp documentation. So incredibly myopic..and damaging..even for their relationship with debian because the binary ppa junk isn't a win for them either. Maddening, absolutely maddening in the lack of basic understanding of how to be an effective upstream project that makes it possible for drive-by externals to pull/build/test your project code. So having me walk into a devel list in this mindset right now is basically asking me to walk in and self destruct constructive discussion. So shame on you for encouraging me to sign up on the mailinglist while also pushing my buttons and getting me all frothy. You are a bad person.
Posted Jun 19, 2013 19:43 UTC (Wed) by maxiaojun (subscriber, #91482)
As you already contacted upstream, you are all set now. Response time from free software project is indeed random. Sometimes multiple pokes are needed.
Posted Jun 19, 2013 21:21 UTC (Wed) by jspaleta (subscriber, #50639)
The motto: "never ascribe to malice what can be accounted for by incompetence" is certainly applicable here.
And I'm more than willing to chalk up everything that as so far raised my ire in this matter to frustrating incompetence rather than delibrate malice aimed in my direction. Speaking of which, I wonder if anyone has ever watch the old Keystone Cops serials and thought the cops were acting in a malicious or devious manner. Food for thought.
Though I really not sure casting all other parties in the discussion as incompetent is really going to help resolve technical difficulties getting mir testable outside of an Ubuntu environment. So meh.
-jef"I'm not incompetent so I guess that makes me malicious...and I'm okay with that."spaleta
Posted Jun 19, 2013 20:03 UTC (Wed) by maxiaojun (subscriber, #91482)
Well, I downloaded the source package you probably looking for from https://launchpad.net/~mir-team/+archive/staging/+files/m...
Which can be found in https://launchpad.net/~mir-team/+archive/staging/+packages (click the triangle before the package you interested)
PPA is something far from ideal. But you probably not know it well enough before making bold claims.
Posted Jun 19, 2013 20:19 UTC (Wed) by jspaleta (subscriber, #50639)
This is so backwards... bzr and git exist for a reason...having to dig into the deb src package is a huge waste of time and its the wrong tool for the job and its not how the internal team works with the code..they work with bzr branches...surely. Don't make scrounge around with over the wall patchsets like im a 2nd class dev..document the actual workflow pretending you actually want extern developers who are _peers_ and maybe you'll actually grow some.
Posted Jun 20, 2013 4:19 UTC (Thu) by maxiaojun (subscriber, #91482)
But finding patches in a Debian source package is quite trivial I'd say.
Just uncompress, cd XXX/debian/patches , that's it.
In this particular, XXX=workspace, a bit strange should be same as package name in most cases.
And the patch you are looking for should be egl-platform-mir.patch; quite obvious from filenames.
Posted Jun 20, 2013 5:10 UTC (Thu) by jspaleta (subscriber, #50639)
Sadly it seems I have to put away the more subtle ax I have been using to hack away at this discussion and pull out the rhetorical spoon and get to the heart of the matter (Double points if you can name the movie I am not so obliquely referring to in this sentence).
It's not about pulling the patch today. Its about tracking mir development like a grown-up developer wearing his big-boy pants does every day. Pulling the blasted patch from the bloody stupid debian source package is a waste of my time. Difficult to believe but more a waste than continuing to talk to you here. Its absolutely arse-backwards way of dealing with tracking a moving development target. Doubly so when the moving target spans multiple codebases and you need to keep them in sync due to API shifts and whatnot. GNOME gets a lot of crap from a lot of people... but the jhbuild tool its pretty awesome bit of work as an on-ramp to working with GNOME development tip in a coherent fashion without screwing up your running environment. Its everything Canonical has failed to do with their ppa tooling to make working with fast rate of churn development code from source without jeopardizing a running environment.
Anyways back to MIR/Mesa. The Bzr branches in lp exist for exactly the purpose of allowing developers to easily track development like I need as an external and are used day to day by the mir team to land changes. The frelling debian source package in the ppa is a carnival sideshow. NOBODY WORKS WITH THAT POS WHEN ACTUALLY DOING DEVELOPMENT ON THE CODEBASES IN QUESTION. Its simply a side-effect of their distribution specific automation for building an testing binaries that target Ubuntu. That's all it is, and its pointless for me to use that as a starting point to track development.
A set of Bzr branches representing the full state of the mir codebase...including the necessary and yet to be merged mesa patchset..is what I frelling expect to be pointed to. The exact blasted branches that the internal fracking development team inside the Canonical fenceline is bloody patching and using day-to-day so I can just as easily pull the branches remotely and keep up with the changes on a change by fracking change basis.
Unpacking a frelling debian patchset every freaking day... its just moronic, clearly suggested by someone who has never made the attempt to track a project in this fashion. Its insulting to me even to have you suggest that as a valuable use of my time actually considering the availability of the bzr/git tooling that is being used as part of the daily development process. Stop being insulting, if you are sincerely attempting to help me then find the bloody undocumented and unpublished mesa bzr/git branch that its being sucked into the daily deb build automation that I can clone and use to construct patch merge requests with. Don't point me to secondary unused src format, to pull apart frelling manually, that are purely the result of build infrastructure implementation choices that are not part of the development workflow.
The bzr/git branches are the _thing_ that developers are working with. Give me the thing...give me the hotness...not the cast off debian source detritus and make it sound like I should be happy to even have that. No sir. anything less than the bzr/git branches that represent the tip of upto the minute development will simply not do.. any clever workaround involving the debian source package and its payload is just a hack and its not worth the time to even describe to me as if I don't bloody know what the debian package payload looks like.
I know what a debian package is, thank you very much, I know how to deconstruct them to get access to patches and I'm telling you its a frelling waste of my time to do it even once for Mir. Stop insinuating that I don't know how deb packaging infrastructure works like I'm some noob. Pulling apart automated launchpad deb builds wasn't productive when I originally did it back when Shuttleworth made his cash investment in to the fledgling Eucalyptus and eucalyptus was being developed in private launchpad bzr branches ahead of the UEC announcement and all I could see were the debian source packages being pooped out with the prerelease binary packages...and its not productive now with Mir. It will never be productive for any external developer to attempt to work with a canonical controlled codebase in the way you are suggesting. I've been beating this particular dead horse for a while now and I'm simply done bending over backwards trying to keep track of Canonical projects by picking apart the debs they poop out of their automation tooling. When I say their handling of on-ramps for external developers has been historically a shambles and that I feel its indicative of a corporate culture that doesn't know what it means to get the basics of being an upstream project right... I mean it. I really really mean it. And this is me...being polite...about how I feel about it too. Pray you never see me be more honest than polite about this topic.
Tweetspeak: No sir. I need bzr/git branches to track dev, nothing less will satisfy
Posted Jun 21, 2013 5:33 UTC (Fri) by maxiaojun (subscriber, #91482)
( Got this answer from mir-devel )
Posted Jun 21, 2013 12:05 UTC (Fri) by wookey (subscriber, #5501)
Neverthless, some of us are old-fashioned and _do_ like working with debs and patches rather than git/bzr/whatever. Yes it's crufty and way uncool but I actually understand what I'm doing in this environment (as opposed to git/bzr where it can take hours to generate a simple patch against what I wanted). Mostly this is my own incompetence, but I still find life a lot more productive, despite some irritations, with simple packaged sources than VCSes (especially if that VCS is git). Just to say such people do still exist.
So from my POV what the Mir people are providing sounds ideal. (Although in the wider context I don't understand why Mir was necessary - it seems to me that existing projects already covered what was needed, but there you go).
Posted Jun 21, 2013 19:04 UTC (Fri) by jspaleta (subscriber, #50639)
Posted Jun 22, 2013 14:26 UTC (Sat) by tzafrir (subscriber, #11501)
So your preference does not apply to this case.
Posted Jun 19, 2013 18:54 UTC (Wed) by maxiaojun (subscriber, #91482)
But again, isn't the way to solve this kind of issues "ask the upstream" rather than "complain on LWN"?
Posted Jun 19, 2013 18:42 UTC (Wed) by maxiaojun (subscriber, #91482)
Posted Jun 19, 2013 18:48 UTC (Wed) by jspaleta (subscriber, #50639)
but with the url changed as necessary
And point of fact... mesa build instructions include a list of versioned project dependencies... just ahead of the distribution specific instructions. So yes I can build build mesa just find outside of fedora with the provide information. The versioned Xorg codebase information on the same page as the yum instructions is a sufficient breadcrumb.
Posted Jun 20, 2013 12:18 UTC (Thu) by 3v1n0 (guest, #88377)
Posted Jun 20, 2013 14:17 UTC (Thu) by jspaleta (subscriber, #50639)
All I need is for the url for the mesa bzr/git branch, which include the egl mesa backend code for mir, to be added to those instructions. So I can pull _all_ the mir related code that represents the tip of mir development into a clean environment and build/test.
Or I can wait till the mesa patches are properly upstreamed into mesa development. But its not necessary to wait that long to do initial build/testing if the pre-merged mesa patch branches were published and made consumable by externals. Either way, there's no point in anyone wasting more time trying to get Mir to build outside of Ubuntu, until the corresponding mesa backend code is published as part of either a git or bzr branch somewhere.
Posted Jun 20, 2013 22:45 UTC (Thu) by mjblenner (subscriber, #53463)
linked from https://launchpad.net/mir/mesa
Posted Jun 20, 2013 23:26 UTC (Thu) by jspaleta (subscriber, #50639)
Hopefully this is enough to get a testable mir binary built outside of Ubuntu.
Though it would be reassuring if roaf blessed the github repo as matching mir tip in some ornate ceremonial ritual blessing...or just an update to the mir build from source instructions. But in the meantime... tallyho!
Posted Jun 27, 2013 17:16 UTC (Thu) by farnz (guest, #17727)
So, to give you one example of the problem; I can contribute (per my employment contract) to any open source project as long as I get the work as a whole under the same license as I am placing my contribution under.
This means that (for example), I can contribute to the Linux kernel - I give code under GPLv2, and get it back under GPLv2. I can contribute to KWin - I give code under GPLv2+, I receive code back under GPLv2+. I can contribute to Wayland - I give code under MIT, I receive code back under MIT. I can't contribute to Mir without getting my employer's explicit consent; I would contribute under the permissive licence grant in the CLA, and receive back under GPLv3 only. That's not something I'm permitted to do without a lot of hassle, so I'm never going to bother looking at Mir unless my employer asks me to.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds