[Development] Qt branches & proposal how to continue with those
Jani Heikkinen
jani.heikkinen at qt.io
Mon Jan 29 11:10:22 CET 2018
> -----Original Message-----
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt-
> project.org] On Behalf Of Giuseppe D'Angelo
> Sent: maanantai 29. tammikuuta 2018 11.31
> To: development at qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
>
> On 29/01/18 07:59, Jani Heikkinen wrote:
> > We have currently really many branches open:
> > - 5.6
> > - 5.9
> > - 5.10
> > - 5.10.1
> > - 5.11
> > - dev
> >
> > In my opinion this is too much to handle effectively, especially because there is
> many branches in stable mode (see
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in
> 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change
> that to be able to work efficiently & get releases out.
>
> Could you please elaborate, what's the problem at the moment when you say
> that it's "too much" to handle? Is it a matter that branches have become
> different enough that merges don't apply any longer? Is it a matter of bandwidth
> for the releasing team having to produce releases from several branches?
The problem is resource usage side at the moment. I think merges are still applying quite well but it is really big effort needed to do merges from ('5.9.x')->'5.9' ->(5.10.x)->'5.10'->'5.11'->'dev'. This is manpower, hw capasity and timing issue: It takes really long time to get a fix in every branch where it is needed and it also consumes lots of hw capasity to run CI on all these branches + run qt5.git integrations. And of course it is really hard for release team to get that much releases out (also HW usage point of view: RTA uses quite much resources while testing all these releases and snapshots).
Moving '5.9' to strict mode helps there with merges and removing one release would help with all these issues, that's why I did this proposal.
br,
Jani
More information about the Development
mailing list