Avoiding fragmentation with a rolling release

[Evan Dandrea]

On Mon, Mar 4, 2013 at 1:16 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> 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.

I don't mean this as a personal slight if it has come across as such. I'm not
proposing that you're arguing we switch back to GI, but your mention of it
raises an opportunity to look back on that experience and define new processes
that learn from our past mistakes.

> 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 Nokia/Digia.

I think this is why it's important to start the process of nailing down the
APIs we care about, drawing a firm line in the sand between the things we can
document, test, and support with *complete* bindings, and those that we cannot.
If Python is important to us and we don't have time to ensure complete Python
coverage with tests for each method, then we shouldn't be advocating any
library which doesn't include full Python support.

This is critical. If we cannot support something fully, lets make sure we don't
ever suggest it or make promises about its maintenance. Better to be narrow
than lead people down the garden path. We've failed when developers find the
APIs they were using fall short ("you can't do that in Quickly"), disappear, or
completely change in the next release. When developers cannot guess the methods
of the API because they were written for an entirely different language
audience, again we fail.

We'll be in a much more tenable position to carry the same set of APIs from
release to release and be better positioned if one of those API providers goes
off the reservation when we've picked a finite set. I don't think anyone is
going to make the argument that we can do the same thing with the rats nest of
APIs we have in main today.

Now, my point wasn't that in Nokia/Digia we magically have all these things. My
point was that we should care about these things more than the sheer volume of
APIs we can provide with an automatically generated solution or blindly letting
someone pick up the maintenance for us.

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

Sure. I want to be cautious about it as well. I'm advocating we do it, but we
pick some subset for which we can do it really well.

> "From exceptions to segfaults" is quite a harsh exaggeration.

>> from gi.repository import GdkX11
>> GdkX11.get_default_xdisplay()
[1]    10593 segmentation fault (core dumped)  ipython

>> import gtk
>> gtk.gdk.display_get_default()
None

Also:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/950087

Now one can argue as you did in the latter bug report that the developer is
doing it wrong, but this is the sort of problem that did not exist with pygtk.

I think it also speaks to the problem faced whenever you mechanically generate
bindings. These are not Pythonic. For someone versed in that language, writing
Object.new() is entirely alien.

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

That of course assumes we pick Python as the language for graphical
applications and services. Last I checked, it wasn't the fastest thing going on
an ARM processor. And the system requirements should bar it from ever being
used for a long-running (ubuntuone-syncdaemon) or frequent process (Lenses).

Developers of all stripes have written over 700,000 applications for iOS in
Objective-C. What's so bad about telling people that they should write C++ with
UI in Javascript?

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

Agreed. If you're writing something that's effectively a webkit window with
extra glue to talk to the notifications system, address book, and so on, your
use of the system APIs will be minimal.

>> With Qt/QML we have a real chance to focus on things that /matter/:
>
> Let's hope for the best. :-)

Well, I was hoping that we could put a few stakes in the ground and say that
careful API cultivation and nurturing was something we really care about. Build
it into the process so that we don't blindly pull in the new hotness in a year
or two. Start making acceptance of new API methods into the core platform
require full test coverage, full higher-level language support (if we've said
we care about any), and complete documentation in the canonical source
(developer.ubuntu.com) with examples.

Even if we have to pick a completely new set of APIs in a few years due to some
catastrophe, we at least know what developers are all coming from and where
they're all going to read the docs. We can provide them a comfortable path
forward and thereby increase the number of applications that continue to work
after that transition.

Or we could keep creating choose your own adventures of pain:
http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png

And watch as hundreds of thousands more interesting applications are written
for other platforms while we're stuck with the handful written by the toolkit
maintainers.