Avoiding fragmentation with a rolling release

Martin Pitt martin.pitt at ubuntu.com
Mon Mar 4 13:16:59 UTC 2013

Evan Dandrea [2013-03-04 11:24 +0000]:
> If we're committed to leaving ourselves the option to change the
> entire development stack ever year, we won't have very many high
> quality developers or applications on our platform. Could we not
> instead say, "enough is enough" and commit ourselves to providing
> whatever changes need to be made in the coming years to ensure that
> QML is keeping third-party application developers happy and committed
> to us?

I was merely pointing out what happened in the past.

Sure we can claim "Qt5/QML is _the_ development API" now. If there is
some indication that this will last longer than what we had before,
that would be great of course. But keep in mind that we do not own,
and do not even (significantly) contribute to Qt/QML development, so
we are again completely dependent on another company, and we all know
how many changes there have been in the past few years with

So don't get me wrong, I'm not at all opposed to stable development
APIs. I'm just saying that we should be very cautious of claiming
"stable for many years" about things that are not in our control.

> You mention gobject-introspection and I think it's the perfect
> example of this. We had an antiquated but largely functional toolkit
> in pygtk2, then one day they decided that it would be better to
> generate bindings based on introspection. What did we get in return?
> Python applications that segfaulted instead of raising exceptions.
> Literally no Python documentation for ages. Sparse examples and
> missing pieces.

"From exceptions to segfaults" is quite a harsh exaggeration. But what
do we get from switching from GI to QML? We won't have bindings to a
great many libraries at all any more, and now have to go back to
writing C++ stubs for those. I. e. exactly the problem that GI already
fixed.  But I guess in the world of mobile apps which mostly deal with
web access and local rendering there are much fewer requirements to
local APIs. 

> With Qt/QML we have a real chance to focus on things that /matter/:

Let's hope for the best. :-)


Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

More information about the ubuntu-devel mailing list