[Development] Which changes are suitable for 5.6?

[Olivier Goffart]

On Dienstag, 16. August 2016 10:48:27 CEST Marc Mutz wrote:
> On Tuesday 16 August 2016 10:06:09 Olivier Goffart wrote:
> > On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote:
> [...]
> 
> > > I agree with Marc, we should allow fixing bugs besides those that are
> > > critical or regressions. Even the regression category will change: once
> > > 5.6 is a year old, we'll start making judgement calls that we "had
> > > better leave it this way".
> > > 
> > > I would prefer we do fix bugs that we can, so long as we can reasonably
> > > say that they are reasonably safe of causing further issues. At least
> > > for the next six months.
> > > 
> > > We should probably become progressively stricter as the branch becomes
> > > older.
> > 
> > Any rationale for this way?
> > I disagree that we should fix non-critical bugs or regression.
> > 
> > If the bug has been there for several years already and the user could
> > live
> > with it, they can continue to work it around unti they upgrade to the
> > newer
> > Qt. It can be seen as a feature.
> > 
> > Our product is the latest version of Qt. LTS means previous versions stay
> > supported, not actively developped.
> 
> The rationale IMHO is a direct consequence of the target audience of an LTS.
> What's the purpose of an LTS? Why do we jump through hoops to mainain an
> outdated codebase for three year?

The purpose of the LTS is too keep that version working.
The reason we should limit the changes to critical change is so than "jumping 
through hoops" gets easier. Every patch we put there instead of in a upper 
branch makes more work of merging, handling regressions causing by this patch, 
having to work with an outdated code base.

(In fact, I think maybe we should stop merging 5.6. Backporting (chery-pick) 
proven patches might be more effective.)


> Because the LTS is for users who _cannot_ update to newer Qts (for whatever
> reason, dropped platforms just being one of them). Pointing them to a newer
> Qt where their bug is fixed is not going to help them one bit.

You could say the same about any new feature. An user requesting a feature 
might still be on LTS and pointing them at the feature in a newer version 
might not be helpfull.   But in the end, we want our users to upgrade. So they 
can reconsider the reason they cannot upgrade while weighing the new features/
bugfixes in the equation.


The question also is what is a bug fix?
The change in question is this one:
https://codereview.qt-project.org/167238
The bug was already existing in Qt 4.x since the feature was introduced. 
People have been able to wait so many years, they can continue waiting.
In fact, this "bugfix" is a "feature".
The change looks harmless, but maybe this suddenly cause augly flickering in 
some cases and we don't know. I've seen enough trivial patches making feature 
unusable.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org