[Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed"

[Olivier Goffart]

Am Mittwoch, 24. Februar 2016, 15:13:10 CET schrieb Thiago Macieira:
> On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote:
> > So my question or suggestion to reduced bug fixing time is:
> > 
> > - Is there or should there be an authority/committee that decides early,
> > if a bug is worth to be fixed for 5.6 LTS?
> > 
> >    Maybe in bugreports.qt.io: if the "Affects Version/s" contains
> > 
> > "5.6.x" the authority
> > 
> >    could "Label" it 5.6-LTS to hint the fixing branch?
> > 
> > - Is there or should there be a Wiki-Page giving rules of thump, what
> > inconsistent between API docs and actual behavior
> > 
> >    is a bug that should be fixed in 5.6 LTS?
> 
> The current rule should still apply: contributors decide among themselves.
> The author of the patch makes a suggestion, other contributors and
> approvers may make different suggestions. In case there's no consensus, the
> maintainer makes a decision.

The problem is that then not the same standards are applied to everything.

> In case there's disagreement with the maintainer's decision, bring it to the
> mailing list and the Chief Maintainer will decide.
> 
> Using bugreports.qt.io won't help, since the same people who can set labels
> and the version fields are the ones in the group above anyway.
> 
> I really oppose the creation of a committee. We don't need more bureaucracy,
> especially without a proof that the current methods don't work. I think the
> above description does work.
> 
> However, a wiki page giving rules of thumb of what may be acceptable and
> what may not is a very good idea.

There is already a wiki page about that.
https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F

Should it be relaxed to more changes "because it is a LTS"?

I don't really understand why make a difference between bugs that are not 
regressions, and new features. Fixing bugs is usually changing behaviour and 
touching existing code which makes it more risky to introduces new bugs or 
break existing applications.  New feature on the other hand, since they add 
new code, are less likely to break applications.

-- 
Olivier 

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