Avoiding fragmentation with a rolling release

[Evan Dandrea]

On Sat, Mar 2, 2013 at 9:11 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Loïc Minier [2013-03-01 12:10 +0100]:
>> I don't think we can make any commitment against all of Ubuntu or all of
>> main, but we could pick a subset by product and commit to some level of
>> API and ABI support for this subset.
>
> I still disagree. A few years ago we heavily promoted quickly+pygtk2
> as THE app dev platform, only to deprecate it about a year later when
> gobject-introspection and GTK3 came along. After that has caught on
> for a while, we are now telling people "forget about GTK, use Qt/QML
> as app dev API". The former was already on the horizon at that time,
> and we were fully responsible for the latter by ourselves.
>
> Who knows what the app dev API du jour will be after 14.04? It's not
> totally inconceivable that we'll go back to e. g. GI and JavaScript,
> as upstream GNOME currently intends to do, or even to different APIs
> that are being used by other OSes (Android, FirefoxOS, and the like).
>
> We shouldn't make promises which we cannot guarantee to hold, so let's
> rather be clear and say "this is the API for *this* LTS".

Hi Martin,

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?

Why would we have to continue to be dragged along the upstream GNOME
path? This is a group that seems to care more about throwing new code
over the wall than adequately nurturing a development platform. 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.

GNOME is going in a different direction than us. They care about
different things. The perceived savings of letting them run the
development stack will vanish when we have to do herculean work to fix
things like gobject-introspection.

With Qt/QML we have a real chance to focus on things that /matter/:
comprehensive documentation, a stable API with a clear deprecation
plan, unit testing of the entire API, consistency and guessability
across the API, tooling to ensure the best out of box experience for
application development and publication, reducing the number of code
changes developers need to make just to keep their application running
in later versions, and so on.

Sure, maybe someday we need to extend our APIs because third-party
application developers are calling for some specific new ones after
experiences on Android or elsewhere, but lets do it because prominent
application developers are asking for it, not just because GNOME
suddenly fancies Dart.