[Development] Changes to Qt offering

[Edward Welbourne]

Il 29/01/20 09:52, Cristián Maureira-Fredes ha scritto:
>> Regarding the LTS decision, you can take it from another point of
>> view: 5.15 will only have 2 or 3 bug fixing releases, and so will all
>> the LTS versions in the future.  Since TQtC has commercial costumers,
>> we will internally fork the latest bug fix release, and will start
>> adding patches on top of that on request of the costumers, but hey!
>> all those patches will be on Gerrit, so if they are important for
>> your work, you can just cherry pick them to your local Qt and
>> re-build.

Giuseppe D'Angelo (29 January 2020 10:36) ha scritto:
> Ok, finally some answers here.
>
> I don't understand this model at all: if in the long run 5.15 is going
> to be maintained as a private fork, but all the patches to it are
> going to be public on gerrit, it's going to take approximately 20
> minutes for someone to
> * set up a gerrit stream
> * get all the merged patches targeting this "5.15-private" branch
> * cherry pick them on 5.15.x
> * publish the result (5.15.oss-latest) on github or KDE or so

Clarification: we'll be moving to "all commits land first on dev and are
cherry-picked out to other branches that need them" in place of our
present merge-based module.  Where Cristián says "all those patches will
be on Gerrit", they'll be on dev on Gerrit.  They'll be cherry-picked
from there to a (presumably) private branch (maybe on a private repo),
so you won't necessarily see the cherry-picked versions, only the dev
versions.  So any time the cherry-pick requires adaptation to the LTS,
those running the fork above would need to duplicate the adaptation.

Not claiming this contradicts the general thrust of your case, just
clarifying what that case would mean in practice.

	Eddy.