Re: [Development] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming...

2016-08-16 Thread Jani Heikkinen
Hi all,

We have still issues with qt5.git integration in 'dev' and some configuration 
system related changes are missing as well. That's why we agreed to postpone 
final branching () a bit in today's release team meeting (memo coming 
later). New target is Monday 22nd August 2016.

Please do not merge new stuff into dev (that's not strictly required for 5.8) 
at this point to help us with qt5.git integration. Especially please avoid 
changes to public or internal APIs for this one week.

Br,
Jani

From: Jani Heikkinen
Sent: 8. elokuuta 2016 13:58
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze 
coming...


Hi all,



Qt5.git integration in 'dev' succeed during the weekend and we have soft 
branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th 
August 2016 as well as final branching from 'dev' to '5.8'



So please start using '5.8' for changes targeted to Qt 5.8 release and finalize 
ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen Monday 
15th Aug (morning).



Please make sure

- All new modules for Qt 5.8 are in 'dev' & part of qt5.git

- All mandatory new features are in 'dev' now or coming in within a week?

- New feature page contains all new features etc: 
https://wiki.qt.io/New_Features_in_Qt_5.8



We will create first src packages from latest qt5.git integration as soon as 
possible. Please check the packages immediately when available to see if 
something important is missing. Those packages should be quite close to Qt 5.8 
alpha packages so it will be really important to check the packages now.


br,
Jani



Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io



[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Which changes are suitable for 5.6?

2016-08-16 Thread Jędrzej Nowacki
On fredag 12. august 2016 10.52.52 CEST Marc Mutz wrote:
> Hi,
> 
> I'd like to know what the rules are supposed to for submitting to 5.6 (LTS).
> 
> Should we enforce the strict rules of other minor releases (only regressions
> and P2+)?
I strongly believe that autotests improvements should go to LTS, flaky and 
broken tests affect all branches.
 
Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Which changes are suitable for 5.6?

2016-08-16 Thread Marc Mutz
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?

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.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Which changes are suitable for 5.6?

2016-08-16 Thread Olivier Goffart
On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote:
> On sexta-feira, 12 de agosto de 2016 14:00:10 PDT Marc Mutz wrote:
> > Well, we told people "look, Qt 5.7 will drop support for your platform,
> > and
> > require C++11, but don't worry: you have 5.6 LTS". I doubt those people
> > would be happy if they didn't get their bugs fixed because they don't
> > involve crashes or security exploits.
> > 
> > And if you look at what goes into 5.6, I don't buy that they're all
> > critical  crash or security fixes. The masses vote with their feet. Don't
> > shoot the messenger. I think 5.6 is better for it. _Now_ you can shoot :)
> 
> 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.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development