[Development] Where and how does Qt define which platforms are supported?

Thiago Macieira thiago.macieira at intel.com
Fri Oct 25 00:04:49 CEST 2013


On quinta-feira, 24 de outubro de 2013 22:59:37, André Pönitz wrote:
> And half of the problem is unsolved. From a Qt user's perspective there's
> quite some difference between "Tier 2 - happens to work now, but is left to
> rot and die" and "Tier 2 - intended to be Tier 1, but fumbled at the
> latest release" when trying to judge whether Qt will be suitable for his
> product.

So you want the first derivative of the Tier? :-)

Yeah, sure, we can list how a given platform has been progressing.

Anyway, the point is that a platform that is currently at Tier 1 level will 
probably remain usable for the next 2 releases or more, even if we fumble the 
releases for it. That means users can make reasonable educated guesses about 
what platforms they can invest on.

I don't think the Qt Project can give more guarantee than that. The Qt Project 
doesn't have anyone working for it and I, for example, can't tell anyone what 
to do.

If a user wants more guarantee than that, I can think of two ways:
 1) joining the project and putting people to work on supporting that platform
 2) paying someone else to do it

See below for a slightly modified proposal.

> > The Tier levels are for users to know what they can rely on: does Qt work
> > on  that platform and can I count on it to continue working in the medium
> > term.
> This "medium term" perspective contradicts what you stated above about "at
> release time". 

So let me be clear what I meant: at the release time, we determine which 
platforms are likely to supported for the medium term. Platforms for which 
there's a healthy team, for which the tests are passing and are getting 
executed frequently, are likely to remain so for some time. If we do detect a 
decline in the next release, we should be clear to the users that there has 
been reduction in activity and only time will tell whether this was temporary 
or permanent. I think that's fair.

> As I said, "actual" and "intended" should be separated, and communicated.
> _Clearly_.

Agreed. I'm not saying anything *at* *all* about intended. The Qt Project can 
intend all it wants, but if no one actually does the work, intentions are 
meaningless. The project can only talk about what actually happened.

At best, we can talk about what the trend is. For example, we can reasonably 
expect right now that Qt 5.2 will have QNX/BB10, Linux/X11, Windows, OS X, and 
Android as Tier 1, and iOS remains to be seen (it's its first release, after 
all). We can say that because we can see that people are working on those 
platforms. Similarly, we know of exactly one person working on FreeBSD, and 
we've seen a handful of patches for Solaris coming a couple of months ago -- 
those platforms are trending to Tier 2. That's based on *reality*.


Anyway, here's an alternative:

We modify the "reference platform" definition to be more flexible and change 
over time. That means the project starts requiring work on some platforms and 
will dedicate resources to them even if the original team disappears.

The Linux kernel does that: once a driver is upgraded from "drivers/staging" 
(a.k.a. TAINT_CRAP) into the regular ones, it gets maintained even if the 
original maintainer disappears. It gets fixed if there are changes elsewhere 
that break it.

GCC does that for its platforms too: once it's supported, it remains supported 
for at least two releases. If the team behind a platform disappears, the 
platform is mentioned in the release notes saying "it will be removed in the 
next if no one steps up to maintain it".

So, for Qt, we could adapt our reference platforms over time to match the 
actual work happening. We're not stupid: we'll only accept platforms into the 
reference category if we see that there is actually interest in them and a 
reasonable community of people who can  maintain it. We're not going to accept 
code dumps (neither the kernel nor GCC do it -- see Linus's latest rant 
against Linaro drivers).

If we do adopt this categorisation, then I'd like to modify the tier system so 
we don't end up with four levels. Unless people actually like:

	Tier 3
	Tier 2
	Tier 1
	Tier 1 LTS

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131024/85e21ce0/attachment.sig>


More information about the Development mailing list