[Development] Which changes are suitable for 5.6?

[Marc Mutz]

On Wednesday 07 September 2016 10:26:44 Olivier Goffart wrote:
> 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.

You're evading with a null argument: Keep it working _for_ _whom_?

> 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.)

IMO, that's nonsense. I still remember this from 4.8. No thanks. Why work 
against the (very good!) revision control system?

Anyway, seeing as neither you nor me are doing merges, I guess we should let 
that particular topic in peace for Liang and Eddy to comment on, if they so 
wish.

> > 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.

Of course not. A user needs to write code to use a new feature. A bugfix 
affects existing code.

> 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?

You seem to want to imply that bug fixes are just some form of feature. If you 
do, then I disagree.

A bug fix is a mismatch between documented[1] and actual behaviour. The fix 
_either_ fixes the docs _or_ the code, but not both.

Features don't have this property: You change the docs _and_ the code.

So that particular line is easy to draw, even though, of course, there's, as 
always, a grey area.

[1] Documented as in qdoc, or implied by reasonable expectation, e.g. "works 
like in a native application", "does not invoke UB".

> 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".

No. It does not change both docs and code, only code, and makes Qt behave as a 
native application (try it in IE/Edge, e.g.).

> 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.

If that should be the case, we will add another patch. We don't release 5.6 
immediately after each commit, so there's some time in which regressions can 
be discovered.

In general, it makes no sense to not fix bugs because you might introduce 
bugs. Even if you add one bug per two bugs fixed, you end up with less bugs at 
the end.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts