

Mir in Kubuntu - Tsiolkovsky
http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/

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

------
lmm
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
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
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
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.

~~~
dragonwriter
> There is a large overhead when doing TDD.

I don't think that's true.

There may be a requirement to do unsexy tasks that volunteers aren't
interested in, but the actual overhead to create software that works as
intended is lower doing TDD than without it, which is the whole _point_ of
TDD.

~~~
zaphar
TDD creates a large maintenance overhead. It more than doubles the code that
has to be maintained for the lifetime of the software. This is by design since
any modification to the codebase should start with a modification to the
tests.

In reality though the tests often bitrot faster than the actual code does. The
cost of the very large set of unittests generated by TDD only grows over time
without contributing to the actual feature set of the software being
developed. For this reason TDD does in fact introduce a large overhead with a
potential savings in safety.

The controversy is introduced when people start to realize that the most bang
for the buck comes from tests that exercise the public interfaces of the
various parts of the software and that less and less benefit comes from the
tests covering the internal parts of the software. Often the fine grained
tests covering the internal details cause the internals to ossify and increase
the cost of changes until finally they get abandoned.

TDD has it's place but taken too far it can do just as much harm as the lack
of tests.

~~~
dragonwriter
> The controversy is introduced when people start to realize that the most
> bang for the buck comes from tests that exercise the public interfaces of
> the various parts of the software and that less and less benefit comes from
> the tests covering the internal parts of the software.

That's not TDD being controversial, that's details of how to apply TDD being
controversial at most (and, really, its seems to be a "controversy" that
amounts to saying "doing things that TDD doesn't ever call for is excessive",
with no other side, which isn't a controversy, its a non-sequitur; if you are
creating unit tests for internal details that aren't exposed, you are
_preventing_ refactoring, rather than _enabling_ by testing all and only the
required exposed behavior so that you can refactor the implementation of that
behavior _without changing tests_ , which is a central part of TDD. I suspect
the problem with this is bad _metrics_ used by some people who say they are
doing TDD but have adopted measurements that imply standards that forget about
the entire point of TDD, such as looking to ensure that every method is
directly tested, which is clearly inappropriate.)

------
Zigurd
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."

