On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: > Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto: > > - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to > > merge tags) > > - you may integrate only changes which have been already integrated into > > a stable mainline > > Sorry, but need to raise an objection against this strategy, or at least > ask for many more clarifications about this process. > > To me this looks like asking all contributors to at least double the > effort necessary to fix bugs that are (also) present in 5.6: patch 5.x, > get it merged, cherry-pick to 5.6, get it merged there. > > On average, the cherry-pick to 5.6 will mean rewrite the patch, because: > > 1) The whole motivation for stop doing merges from 5.6 forward is the > high number of conflicts between the branches.
That's not true, it's also about the time it takes for a patch to trickle down from 5.6 to dev to enable dependent work there. > Therefore, I can assume > that conflicts will be also be hit when cherry-picking back. E.f.s.q. > So, while on one hand this new branching scheme distributes the burden > from the current merge masters onto the bigger community, in practice > I'm very afraid (read: almost certain) that this will mean that very few > people will be willing to do the extra work, hence leaving 5.6 unpatched > for ordinary, non-critical bug fixes. Being more and more restrictive as the patch levels increase does not really sound like a problem for LTS release. > This makes using a LTS quite less attractive to me. Using with what hat on? People with a "end user programmer hat" want something stable there, no new features. People with a "Qt developer hat" do not want to wait weeks for dependendecies to trickle down. > Are we sure there isn't a better way? I am not sure there isn't, I am just not aware of such either. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
