[Development] Changes to Qt offering

[Thiago Macieira]

On Wednesday, 29 January 2020 13:55:49 PST Alejandro Exojo wrote:
> If we don't have this, we could end up with random projects on
> Gitlab/Github, with custom cherry picks from dev applied, and the community
> effort wasted because it's just plain hard to coordinate for an effort like
> this (without starting a formal, hostile fork). That's typical for projects
> that end up in abandonware status after its popularity peaks on Github, not
> for a supposedly openly governed mature project like Qt. Worse, that's
> making people contributing to Qt... in exactly the opposite way that The Qt
> Company wanted!

And isn't this what creating a branch in the Qt Project infrastructure 
(regardless of who pays for that infra) would accomplish too? We're talking 
about a set of branches maintained by less than one third of the community, 
often missing the key maintainers.

Suppose you make the bugfix to RHI and it gets applied to 6.0. Who approves 
the backport to 5.15?

Of course, the same can be turned around: the Qt Company's branch is also a 
fork, since it is missing nearly a third of the community. Who approves 
backports to QDeadlineTimer? Not me, clearly. The difference is, of course, 
that the Qt Company has far more developers who can look after the areas 
maintained by the rest of the community than the community has to look after 
areas maintained by the Qt Company.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products