9 ms·

Mir in Kubuntu

71 points by Tsiolkovsky 13y ago

lmm 13y ago
There's a lot of truth here but the article seems to overstretch at times. The benefits of TDD are many, and I don't understand the logic of refusing to use a GPLv3 component because you're worried about GPLv4.
- JoachimSchipper 13y ago
  TDD is controversial. Mir is GPLv3; lots of free software, including KDE, is GPLv2+. Incorporating Mir into KDE would move everything to GPLv3; if there is ever a GPLv4, no software under that license could ever be integrated into KDE (since Mir does not have the usual "or a later version" phrase.)
  - Aqueous 13y ago
    I don't really understand why TDD is controversial. When we build software we are building a machine with components. In every other industry where a machine with components is being created they apply test-driven-development. A component is rigorously tested over and over and over again until it meets the specifications. I would not trust a car where every component inside of it wasn't rigorously tested in such a way. Otherwise I cannot credibly make the claim that a bug won't show up when I'm driving the car around on a highway that hadn't appeared in development. TDD doesn't eliminate this risk, but it gets us a lot closer.
    - Elv13 13y ago
      It's free software. There is a large overhead when doing TDD. Such overhead is not practical given the low, voluntary, resources such projects get. Free software project velocity is based on contributions. If you require such contributions to also make tests before committing the code, then you kill the project in a few months. This is why TDD based projects are so few and controversial in the FLOSS world.
      - Aqueous 13y ago
        I think a common misconception about TDD is that it requires a a lot of overhead. It actually reduces overhead because you front-load the quality assurance, and save a lot of time going back and fixing bugs down the road. Some of the most popular open source projects use a lot of test coverage. Some very important projects don't, but I think the only reason Linux, for instance, has gotten away with this is because it has such a gigantic community that finds and fixes a bug immediately if one is found.
        pjmlp 13y ago
        How do you TDD UI code?
        Aqueous 13y ago
        On the web, you can use Selenium and pair it with either a headless browser like PhantomJS and/or a headless virtual machine running IE.
        pjmlp 13y ago
        How you validate if the CSS or HTML is rendered as supposed to be?
        Aqueous 13y ago
        You look at it :-) (Edit: That's not the whole answer. Usually when you test you assert that certain elements of the DOM are where they should be. At the very least you have verified the structure of the HTML document, if not how it looks. For actual aesthetics I can't see any way around human testing.)
        pjmlp 13y ago
        I am just playing devil's advocate. I work for Fortune 500 consulting projects and don't believe in TDD for UI code that works across the myriad of technologies we use in work projects, while scaling across multi-site development. TDD only seems to work on the business logic, and only in code written with testing in mind.
    - jholman 13y ago
      This analogy (machines, cars, etc) is absolutely terrible. No physical-goods manufacturer uses a process comparable to TDD. TDD is not the same as testing. At the risk over oversimplifying, TDD is writing your tests first. AND they need to be automated tests. I bet that never in the history of the world has a car factory been built by starting with the QA line, making sure the QA line is properly robotic, and only after that starting to figure out how to design the parts. ---- I too suspect that automated testing, and possibly TDD, would raise the quality of FLOSS. But I'm not a committer on any of those projects; maybe those guys know something I don't. Or maybe you and I are right. But despite that, TFA has a good point about TDD. He says that "TDD" is listed by Canonical as one of the technical virtues of Mir (I don't know if he's correct about this part). And he says that he does not see that as a technical virtue, in part because lots of the systems that he prefers (for technical reasons) are not using TDD, including his own project. (Also, btw, including the Linux kernel, which I believe has a "think about it really hard, then make sure it compiles, then ship it!" approach to quality control, at least if I read some of Linus's public emails correctly.) I agree that if someone wants to list TDD as a "technical feature", they're reaching.
      - Aqueous 13y ago
        I need to clarify. I'm not talking about manufacturing I'm talking about protoyping and design. Software deevelopment is analogous to making the protoype, not the copies. A replica of the prototype should be able to pass the same tests the prototype can - that's why manufacturers can get away with only testing a sample of them. You can be sure that the protoype has gone through rigorous specifications testing. I think that you can look at part specifications as writing a test. The component we're aiming for has to meet x, y, and z standards. Then you design the component, then you make sure it meets those standards. If not, iterate. Pretty analogous, I'd say.
        jholman 13y ago
        I agree with what you said in THIS comment, but it makes it even more obvious that your previous comment contains untrue statements. You think car manufacturers practice TDD with their prototypes? Ha! People who are building physical prototypes... 1) don't test first (they test AFTER building the prototype), and 2) don't use automated tests to avoid regressions, at least not typically Bottom line, there's nothing even approaching TDD in physical-goods manufacturing. Maybe you don't know what TDD is, and have assumed that "tdd" means "good testing"?
    - hencq 13y ago
      You might be surprised to learn then that you shouldn't trust modern cars. Car manufacturers don't test every part or component that goes into a car. Instead they rely on process control to ensure that said process delivers parts within the specs. Of course this means they'll take regular samples, but the idea behind it is fundamentally different. They're really measuring whether the process is stable and not testing the individual parts.
      - Aqueous 13y ago
        You're talking about the manufacturing of cars, not design and prototyping. The reason that they can take only a representative sample of each component that rolls off the assembly line is that they should be nearly perfect copies of the prototype which most likely did go through rigorous testing. In my analogy, building software is like building the prototype, not building the copies.
        hencq 13y ago
        That's a fair point, but it's also exactly why these comparisons of software engineering to other disciplines never quite work.
  - bratsche 13y ago
    There are also a lot of desktop apps that are GPLv2 that don't have the "or a later version" phrase, which makes them incompatible with GPLv3.
- binarycrusader 13y ago
  I don't understand why Canonical felt the need to use the GPL for such an intimate part of the display stack. I find it hard to believe that the license that Xorg is using has somehow placed it at a disadvantage. If anything, by choice of license, Canonical has ensured that many commercial organizations that contribute to Xorg today may not contribute to Mir.
  - IanChiles 13y ago
    I'm also confused. Because if you now integrate your application with Mir/Unity Next won't you be required to release it under the GPLv3 ?
    - wmf 13y ago
      No more than Linux apps have to be GPL.
kh_hk 13y ago
There's a mirrored version of the article in planet kde: http://planetkde.org/#item-f97a50b7 http://planetkde.org/#item-f97a50b7
Zigurd 13y ago
From all that verbiage I was able to extract that Mir might screw up community supported Ubuntu-derived distributions. I can see how some people would like their road map explained. I was hoping there would be a real comparison of Wayland and Mir development. It seems like they may be identical in effect, and both will enable using Android HAL implementations in mobile devices. I had an occasion to ask a Linux kernel developer about this and got an answer long the lines of "Why ask? Only Ubunutu will use Mir."

71 points by Tsiolkovsky 13y ago

lmm 13y ago

There's a lot of truth here but the article seems to overstretch at times. The benefits of TDD are many, and I don't understand the logic of refusing to use a GPLv3 component because you're worried about GPLv4.

JoachimSchipper 13y ago
TDD is controversial. Mir is GPLv3; lots of free software, including KDE, is GPLv2+. Incorporating Mir into KDE would move everything to GPLv3; if there is ever a GPLv4, no software under that license could ever be integrated into KDE (since Mir does not have the usual "or a later version" phrase.)
- Aqueous 13y ago
  I don't really understand why TDD is controversial. When we build software we are building a machine with components. In every other industry where a machine with components is being created they apply test-driven-development. A component is rigorously tested over and over and over again until it meets the specifications. I would not trust a car where every component inside of it wasn't rigorously tested in such a way. Otherwise I cannot credibly make the claim that a bug won't show up when I'm driving the car around on a highway that hadn't appeared in development. TDD doesn't eliminate this risk, but it gets us a lot closer.
  - Elv13 13y ago
    It's free software. There is a large overhead when doing TDD. Such overhead is not practical given the low, voluntary, resources such projects get. Free software project velocity is based on contributions. If you require such contributions to also make tests before committing the code, then you kill the project in a few months. This is why TDD based projects are so few and controversial in the FLOSS world.
    - Aqueous 13y ago
      I think a common misconception about TDD is that it requires a a lot of overhead. It actually reduces overhead because you front-load the quality assurance, and save a lot of time going back and fixing bugs down the road. Some of the most popular open source projects use a lot of test coverage. Some very important projects don't, but I think the only reason Linux, for instance, has gotten away with this is because it has such a gigantic community that finds and fixes a bug immediately if one is found.
      - pjmlp 13y ago
        How do you TDD UI code?
        Aqueous 13y ago
        On the web, you can use Selenium and pair it with either a headless browser like PhantomJS and/or a headless virtual machine running IE.
        pjmlp 13y ago
        How you validate if the CSS or HTML is rendered as supposed to be?
        Aqueous 13y ago
        You look at it :-) (Edit: That's not the whole answer. Usually when you test you assert that certain elements of the DOM are where they should be. At the very least you have verified the structure of the HTML document, if not how it looks. For actual aesthetics I can't see any way around human testing.)
        pjmlp 13y ago
        I am just playing devil's advocate. I work for Fortune 500 consulting projects and don't believe in TDD for UI code that works across the myriad of technologies we use in work projects, while scaling across multi-site development. TDD only seems to work on the business logic, and only in code written with testing in mind.
  - jholman 13y ago
    This analogy (machines, cars, etc) is absolutely terrible. No physical-goods manufacturer uses a process comparable to TDD. TDD is not the same as testing. At the risk over oversimplifying, TDD is writing your tests first. AND they need to be automated tests. I bet that never in the history of the world has a car factory been built by starting with the QA line, making sure the QA line is properly robotic, and only after that starting to figure out how to design the parts. ---- I too suspect that automated testing, and possibly TDD, would raise the quality of FLOSS. But I'm not a committer on any of those projects; maybe those guys know something I don't. Or maybe you and I are right. But despite that, TFA has a good point about TDD. He says that "TDD" is listed by Canonical as one of the technical virtues of Mir (I don't know if he's correct about this part). And he says that he does not see that as a technical virtue, in part because lots of the systems that he prefers (for technical reasons) are not using TDD, including his own project. (Also, btw, including the Linux kernel, which I believe has a "think about it really hard, then make sure it compiles, then ship it!" approach to quality control, at least if I read some of Linus's public emails correctly.) I agree that if someone wants to list TDD as a "technical feature", they're reaching.
    - Aqueous 13y ago
      I need to clarify. I'm not talking about manufacturing I'm talking about protoyping and design. Software deevelopment is analogous to making the protoype, not the copies. A replica of the prototype should be able to pass the same tests the prototype can - that's why manufacturers can get away with only testing a sample of them. You can be sure that the protoype has gone through rigorous specifications testing. I think that you can look at part specifications as writing a test. The component we're aiming for has to meet x, y, and z standards. Then you design the component, then you make sure it meets those standards. If not, iterate. Pretty analogous, I'd say.
      - jholman 13y ago
        I agree with what you said in THIS comment, but it makes it even more obvious that your previous comment contains untrue statements. You think car manufacturers practice TDD with their prototypes? Ha! People who are building physical prototypes... 1) don't test first (they test AFTER building the prototype), and 2) don't use automated tests to avoid regressions, at least not typically Bottom line, there's nothing even approaching TDD in physical-goods manufacturing. Maybe you don't know what TDD is, and have assumed that "tdd" means "good testing"?
  - hencq 13y ago
    You might be surprised to learn then that you shouldn't trust modern cars. Car manufacturers don't test every part or component that goes into a car. Instead they rely on process control to ensure that said process delivers parts within the specs. Of course this means they'll take regular samples, but the idea behind it is fundamentally different. They're really measuring whether the process is stable and not testing the individual parts.
    - Aqueous 13y ago
      You're talking about the manufacturing of cars, not design and prototyping. The reason that they can take only a representative sample of each component that rolls off the assembly line is that they should be nearly perfect copies of the prototype which most likely did go through rigorous testing. In my analogy, building software is like building the prototype, not building the copies.
      - hencq 13y ago
        That's a fair point, but it's also exactly why these comparisons of software engineering to other disciplines never quite work.
- bratsche 13y ago
  There are also a lot of desktop apps that are GPLv2 that don't have the "or a later version" phrase, which makes them incompatible with GPLv3.
binarycrusader 13y ago
I don't understand why Canonical felt the need to use the GPL for such an intimate part of the display stack. I find it hard to believe that the license that Xorg is using has somehow placed it at a disadvantage. If anything, by choice of license, Canonical has ensured that many commercial organizations that contribute to Xorg today may not contribute to Mir.
- IanChiles 13y ago
  I'm also confused. Because if you now integrate your application with Mir/Unity Next won't you be required to release it under the GPLv3 ?
  - wmf 13y ago
    No more than Linux apps have to be GPL.

kh_hk 13y ago

There's a mirrored version of the article in planet kde: http://planetkde.org/#item-f97a50b7 http://planetkde.org/#item-f97a50b7

Zigurd 13y ago

From all that verbiage I was able to extract that Mir might screw up community supported Ubuntu-derived distributions. I can see how some people would like their road map explained. I was hoping there would be a real comparison of Wayland and Mir development. It seems like they may be identical in effect, and both will enable using Android HAL implementations in mobile devices. I had an occasion to ask a Linux kernel developer about this and got an answer long the lines of "Why ask? Only Ubunutu will use Mir."