Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Sze Howe Koh
On 9 February 2018 at 15:54, Lars Knoll  wrote:
>> On 9 Feb 2018, at 07:52, Kevin Kofler  wrote:
>>
>> André Pönitz wrote:
>>> I think you need to start differentiating between Qt-without-Webengine
>>> and QtWebengine.
>>>
>>> And maybe "we" should do that, too.
>>
>> I would be entirely in favor of separate (more frequent and/or more aligned
>> with Chromium security fixes) QtWebEngine releases. I am already updating
>> QtWebEngine in Fedora on a separate schedule from the core Qt updates (with
>> the intent of delivering security updates faster), so it would not be a
>> problem for me if the releases were entirely separate. And it would surely
>> get security fixes delivered in a more timely manner.
>
> We’ve been discussing this in the past, and most people agreed that releasing 
> QtWebEngine on an independent schedule would be a good thing. But there’s 
> still a couple of things that need sorting out before that can happen, both 
> in the CI and how we create/package our product and SDK as well as in 
> QtWebengine which for example still uses private API of some other parts of 
> Qt.

Is updating the Chromium backend alone a source- and binary-compatible
act? I'm wondering if it's feasible (and desirable) to introduce
"sub-patch" releases, where the only change is the updated Chromium
backend -- not even bugfixes in Qt-controlled code. For example, if
Chromium is updated between Qt 5.10.0 and Qt 5.10.1, then:

1. Branch off the v5.10.0 tag (call it the "5.10.0-x" branch, for
Chromium updates only)
2. Update Chromium in 5.10.0-x and release "Qt WebEngine 5.10.0-1"
3. Merge 5.10.0-x into 5.10

The idea is to provide security updates in a timely manner, without:

* Worrying about private API breakages
* Requiring a full-blown Qt release
* Making Qt WebEngine's version numbering go out of sync with the rest of Qt

This approach would be most beneficial for a non-LTS branch, least
beneficial for an LTS branch in "Very Strict" mode. I thought this
might be an easy option since Qt WebEngine is already listed as a
separate component in the Qt installer (please correct me if I'm
underestimating something in the process).


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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Ville Voutilainen
On 9 February 2018 at 20:46, Ville Voutilainen
 wrote:
>> But I am asking to do a minimal investigation. In most cases of blacklisting,
>> the test has been failing for days, if not months. Spending an hour or two to
>> understand why it's failing and whether it's something that only happens in
>> the CI should be the norm.
>
> The problem is that a large amount of tests have been failing, for
> weeks. In some cases,
> months. In some cases, for a year. That results in a restage storm,
> and carves a doubt
> in every submitter's mind whether CI failures are something to really
> bother about beyond
> hitting the restage button. I doubt either of us thinks that to be optimal.


Also, our blacklist patch submitters *do* minimal investigation and
more. There's been a whole shebang
of suggested flaky tests, which have been deemed to not be caused by
flakiness in tests,
after proper investigation. And another matter to consider is that
both because of CI infra problems
and flaky tests, it's been next to impossible to get anything into
e.g. qtbase for two weeks.
Why some of those flaky tests seem to be hit more often isn't exactly
known, but our statistics
information does support their being flaky, and we've seen every one
of these tests fail before
in spurious manners, we just haven't done anything to it, due to some
extent some people adamantly
opposing blacklisting in general, and some demanding that there's a
thorough investigation almost tantamount
to 100% proof that a test is flaky before a possibly temporary
blacklisting is even considered.

It's also perhaps worth realizing that the current flakiness fixes and
blacklists haven't gone in, because flaky tests here and
there and everywhere prevent integrating those fixes.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Ville Voutilainen
On 9 February 2018 at 20:39, Thiago Macieira  wrote:
> On Friday, 9 February 2018 08:32:20 PST Ville Voutilainen wrote:
>> On 9 February 2018 at 18:17, Thiago Macieira 
> wrote:
>> > We do have BLACKLISTs this time and I complain every time I see one being
>> > added without even an attempt at figuring out what's wrong with the test,
>> > or when the match is overly aggressive ("it fails on Ubuntu in the CI, so
>> > it must
>> It gives me no end of heartburn that we prefer having integrations be
>> blocked for days to doing
>> over-aggressive blacklisting. Having flaky tests is indistinguishable
>> from having no tests at all,
>> so it boggles my mind why some of us are so worried about potentially
>> over-done blacklists.
>
> I'm not asking someone to spend days figuring out what's wrong. I know it
> takes time.
>
> But I am asking to do a minimal investigation. In most cases of blacklisting,
> the test has been failing for days, if not months. Spending an hour or two to
> understand why it's failing and whether it's something that only happens in
> the CI should be the norm.

The problem is that a large amount of tests have been failing, for
weeks. In some cases,
months. In some cases, for a year. That results in a restage storm,
and carves a doubt
in every submitter's mind whether CI failures are something to really
bother about beyond
hitting the restage button. I doubt either of us thinks that to be optimal.

> One of the consequences of blacklisting is that "out of sight is out of mind".
> We'll never remove those blacklists again and that makes us have a false sense
> of security, that we have tested, when in fact we're just ignoring the
> failures. That is just like the Qt CI back in 2006-2009, which is what I said
> I don't want to get back to.


Currently the people working on blacklist patches create a bug report
for every flaky test
that they have to blacklist. Whether we believe those bugs to be
eventually resolved
is another matter, but having every contributor restage every patch
more than half a dozen
times because there are flaky test failures in tests *COMPLETELY*
unrelated to anything
the submitted change does is unacceptable, and it's high time we rectify
that problem, even if a small percentage of our tests gets
overly-aggressively blacklisted.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Thiago Macieira
On Friday, 9 February 2018 08:32:20 PST Ville Voutilainen wrote:
> On 9 February 2018 at 18:17, Thiago Macieira  
wrote:
> > We do have BLACKLISTs this time and I complain every time I see one being
> > added without even an attempt at figuring out what's wrong with the test,
> > or when the match is overly aggressive ("it fails on Ubuntu in the CI, so
> > it must
> It gives me no end of heartburn that we prefer having integrations be
> blocked for days to doing
> over-aggressive blacklisting. Having flaky tests is indistinguishable
> from having no tests at all,
> so it boggles my mind why some of us are so worried about potentially
> over-done blacklists.

I'm not asking someone to spend days figuring out what's wrong. I know it 
takes time.

But I am asking to do a minimal investigation. In most cases of blacklisting, 
the test has been failing for days, if not months. Spending an hour or two to 
understand why it's failing and whether it's something that only happens in 
the CI should be the norm.

One of the consequences of blacklisting is that "out of sight is out of mind". 
We'll never remove those blacklists again and that makes us have a false sense 
of security, that we have tested, when in fact we're just ignoring the 
failures. That is just like the Qt CI back in 2006-2009, which is what I said 
I don't want to get back to.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Ville Voutilainen
On 9 February 2018 at 18:17, Thiago Macieira  wrote:
> We do have BLACKLISTs this time and I complain every time I see one being
> added without even an attempt at figuring out what's wrong with the test, or
> when the match is overly aggressive ("it fails on Ubuntu in the CI, so it must


It gives me no end of heartburn that we prefer having integrations be
blocked for days to doing
over-aggressive blacklisting. Having flaky tests is indistinguishable
from having no tests at all,
so it boggles my mind why some of us are so worried about potentially
over-done blacklists.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Thiago Macieira
On Friday, 9 February 2018 03:07:08 PST Olivier Goffart wrote:
> > Which will happen ALL the time. We'll never get back down: when we
> > released
> > Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only
> > happened for QWS). For the other platforms, the normal number was a
> > hundred
> > tests failing. Then we spent weeks trying to get the number down.
> > 
> > Sorry, I don't want to go back to that.
> 
> That's not exactly how I remember it from the Qt 4.6 and 4.7 times where
> there was no CI yet, but we were actively fixing tests. There were always a
> few red tests on testr.troll.no, but they were mostly flacky tests. What is
> it compared to now with about 100 BLACKLIST files in qtbase alone? (there
> was no blacklist at the time)

Testr is the second generation tool. I am thinking of the previous one, 
reported on desert.troll.no. I remember *once* seeing a "0" test failure 
reported, again QWS.

We do have BLACKLISTs this time and I complain every time I see one being 
added without even an attempt at figuring out what's wrong with the test, or 
when the match is overly aggressive ("it fails on Ubuntu in the CI, so it must 
fail for everyone using Ubuntu!"). But also remember we have more tests than 
10 years ago, probably by a factor of 2. Finally, back then "1" failure 
indicated that the entire test executable failed, whether it was 1 test 
function, 1 test row, or the program crashed.

> > It would not do us well to look at poorer practices than what we have.
> > Just
> > because everyone else is where we were 10 years ago is no reason for us to
> > go back to it. Show us a *better* model, one that still prevents failures
> > from being added, and we'll consider it.
> 
> How pretentious are you, thinking that everybody else has poorer practice?
> Other projects still manage to release product with passing test. And might
> not get ludicrous release delay "because of the CI system" that was supposed
> to help, but gets in the way instead.

I didn't say everyone does. I even gave an example of a project that has 
better practices.

But I am making a subjective judgement that allowing breakages in and then 
fixing them later is a poorer practice. I do not apologise for it.

I am also not saying our method is perfect. Clearly it is not, and that's not 
even talking about the implementation and infra.

> Anyway, here is some example of models which works:
> 
> In LLVM, devs commit directly. buildbots build the trunk continuously. In
> case of failure, the buildbot maintainer quickly find out which commit
> likely broke the test and reverts the commit imediatly (or commit a fix if
> the fix is trivial)

Who reverts the commit, the bot or the maintainer?

If it depends on a person, what happens if the person doesn't?

This sounds like our third-generation CI, when we switched to Git, remember 
that? Each team had a repository, which the CI built and, if it passed, merged 
onto the mainline. If the build was broken, someone in the team had to apply a 
fix or a revert.

Do you remember what happened? It took days to get a failure removed. 
Sometimes upwards of a week, if the attempt at fix did not actually fix the 
issue.

> This works because there are buildbot maintainers taking care of the build
> status, and they are not afraid to revert. Also the build and test time is
> reasonable (while still being big), and individual developer can easily run
> all the tests on their machine before submitting patches. (Very few platform
> specific tests).

Therein lies the problem: for any one developer to run all the Qt tests, it 
takes a LOT of time. And you usually can't use your machine while it runs the 
UI tests.

> On other projects I've seen on github with travis and co.:  the tests are
> run for every pull request individually, before it is integrated. The
> reviewer sees the result of the tests and decide whether to merge on not
> based on the result. If one sees that the failures is obviously unrelated
> to the patch, the reviewer will override and merge anyway.

And I use that for TinyCBOR.

But what happens to pull request B when pull request A is merged? Now the test 
result is stale. It should be re-done by merging the target branch back into 
the PR, or by rebasing (which most projects don't do), to confirm there are no 
issues caused by the combination of changes. More often than not, the 
maintainer applies a judgement call and accepts the stale results.

TinyCBOR has half a dozen .c source files and three QtTest tests (one of them 
is just compilation). It takes about 30 seconds to launch, compile and test 
MSVC 2013, 2015 and 2017 on AppVeyor. But it takes about 8 minutes on Travis. 
Of those, 7 minutes and 30 seconds are spent updating running apt-get.

> I think this model could be easily applied to Qt.

The part where each change is tested before hand, yes. We've always wanted 
this.

The part where changes are merged together and accepted without verifying 
whether 

Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Konstantin Tokarev


09.02.2018, 16:48, "Konstantin Tokarev" :
> 09.02.2018, 10:03, "Kevin Kofler" :
>>  IMHO, you need to rethink your whole CI approach. This is increasingly being
>>  the one bottleneck slowing down Qt development and releases. It might make
>>  more sense to try a different approach, such as allowing all commits through
>>  initially, then making CI runs at regular intervals, and triggering reverts
>>  if things broke.
>
> From what I see, CI is not the bottleneck, or at least not the only one. From 
> reading
> this list I got impression that situation is quite different. We may have 
> stable branch
> with a good number of fresh unreleased commits, but release team rejects 
> possibility
> of making point release, because release process requires a lot of time and 
> they
> need that time for doing something more important [1].
>
> One notable example was with Qt 5.9.3, when Linux binaries were accidentally 
> built
> using too fresh GCC version. It was proposed that we rebuild 5.9.3 tag as is 
> using
> different toolchain, so no new merges were needed and CI delays could have 
> only
> minimal influence on the release timing. Anyway this was rejected, apparently
> because verifying binaries before releasing them requires too much effort [2].

So, I think that instead of putting money into increasing CI capacity, it would 
be better
for TQtC to spend it on the following things:

1. Dedicate enough developers' time into making releasing process (i.e., all 
steps which
have to be done with sources and binaries after Coin integration succeeds) as 
fully
automated as it's feasible

2. Find a way to eleminate Coin downtimes, when it doesn't operate at all or 
uses only
part of capacity

3. Work on eleminating hidded Coin downtimes, when integration time out or fail 
because
of infrastructure issues. I mean cases when compilation does not start or never 
finishes,
independent of code being under integration, so this is totally not about flaky 
tests.

I guess if these issues were solved, current capacity could be good enough to 
reach the
promised land of continuous delivery.

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Konstantin Tokarev


09.02.2018, 10:03, "Kevin Kofler" :
> IMHO, you need to rethink your whole CI approach. This is increasingly being
> the one bottleneck slowing down Qt development and releases. It might make
> more sense to try a different approach, such as allowing all commits through
> initially, then making CI runs at regular intervals, and triggering reverts
> if things broke.

>From what I see, CI is not the bottleneck, or at least not the only one. From 
>reading
this list I got impression that situation is quite different. We may have 
stable branch
with a good number of fresh unreleased commits, but release team rejects 
possibility
of making point release, because release process requires a lot of time and they
need that time for doing something more important [1].

One notable example was with Qt 5.9.3, when Linux binaries were accidentally 
built
using too fresh GCC version. It was proposed that we rebuild 5.9.3 tag as is 
using
different toolchain, so no new merges were needed and CI delays could have only
minimal influence on the release timing. Anyway this was rejected, apparently
because verifying binaries before releasing them requires too much effort [2].


[1] Please don't take this as I'm trying to put a blame on anyone, I'm 
willingly believe
release team is doing their best
[2] https://www.mail-archive.com/development@qt-project.org/msg30384.html

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Ville Voutilainen
On 9 February 2018 at 13:07, Olivier Goffart  wrote:
> Anyway, here is some example of models which works:
>
> In LLVM, devs commit directly. buildbots build the trunk continuously. In case
> of failure, the buildbot maintainer quickly find out which commit likely broke
> the test and reverts the commit imediatly (or commit a fix if the fix is
> trivial)
> This works because there are buildbot maintainers taking care of the build
> status, and they are not afraid to revert. Also the build and test time is
> reasonable (while still being big), and individual developer can easily run
> all the tests on their machine before submitting patches. (Very few platform
> specific tests).

Well, it really can't hurt much to give another example. When I
contribute to GCC, I write
my patch, ssh into a compile farm, pull the repo, apply my patch and
run the testsuite.
After that I submit it for review. There are people running CI-like
build runs, but those don't
block commits. Once a patch has been accepted, I just push it. If
something breaks despite
testing, that's very rare and can be dealt with after-the-fact.

> In Summary: The CI should be a tool helping the development, and not slowing
> it down. And having a way to override the CI for important patches should be
> an easy and quick way to improve things a bit.

Fully agreed, but we already can do such overrides in emergency
situations, and we probably don't
want to enable just everybody to do so. Having said all this, there's
ongoing active work to fix
the CI problems.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Oswald Buddenhagen
On Fri, Feb 09, 2018 at 12:07:08PM +0100, Olivier Goffart wrote:
> On other projects I've seen on github with travis and co.:  the tests are run 
> for every pull request individually, before it is integrated. The reviewer 
> sees the result of the tests and decide whether to merge on not based on the 
> result. If one sees that the failures is obviously unrelated to the patch, 
> the 
> reviewer will override and merge anyway.
> 
> I think this model could be easily applied to Qt.
> 
no, that's exactly the thing that does *not* work for qt. the computing
capacity required to support that model (with the primitive tools we're
apparently capable of utilizing) would be *enormous*.

(of course, one can argue that all the pointlessly failed integrations
effectively thwart the advantage of batch integrations. somebody would
have to do the math to make an actual judgment call.)

another reason why this model may not work too well is qt's abysmal test
coverage in many areas. as annoying as the current system is, it *does*
prevent non-obvious, indirect breakages from going in from time to time,
because people can't just deny responsibility past a certain point.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Konstantin Tokarev


09.02.2018, 14:07, "Olivier Goffart" :
> Am Freitag, 9. Februar 2018, 08:13:01 CET schrieb Thiago Macieira:
>>  On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
>>  > IMHO, you need to rethink your whole CI approach. This is increasingly
>>  > being the one bottleneck slowing down Qt development and releases. It
>>  > might make more sense to try a different approach, such as allowing all
>>  > commits through initially, then making CI runs at regular intervals, and
>>  > triggering reverts if things broke.
>>
>>  Which will happen ALL the time. We'll never get back down: when we released
>>  Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only
>>  happened for QWS). For the other platforms, the normal number was a hundred
>>  tests failing. Then we spent weeks trying to get the number down.
>>
>>  Sorry, I don't want to go back to that.
>
> That's not exactly how I remember it from the Qt 4.6 and 4.7 times where there
> was no CI yet, but we were actively fixing tests. There were always a few red
> tests on testr.troll.no, but they were mostly flacky tests. What is it
> compared to now with about 100 BLACKLIST files in qtbase alone? (there was no
> blacklist at the time)
>
> That said, I agree we should not go back to that.
>
>>  > Qt is being developed very much as a corporate project. (I write "as"
>>  > rather than "like" because that's what Qt is, despite Open Governance.)
>>  > It would help to look at how community Free Software projects do things.
>>  > They tend to be more efficient. And some company-developed Free Software
>>  > projects have already adopted such processes.
>>
>>  It would not do us well to look at poorer practices than what we have. Just
>>  because everyone else is where we were 10 years ago is no reason for us to
>>  go back to it. Show us a *better* model, one that still prevents failures
>>  from being added, and we'll consider it.
>
> How pretentious are you, thinking that everybody else has poorer practice?
> Other projects still manage to release product with passing test. And might
> not get ludicrous release delay "because of the CI system" that was supposed
> to help, but gets in the way instead.
>
> Anyway, here is some example of models which works:
>
> In LLVM, devs commit directly. buildbots build the trunk continuously. In case
> of failure, the buildbot maintainer quickly find out which commit likely broke
> the test and reverts the commit imediatly (or commit a fix if the fix is
> trivial)
> This works because there are buildbot maintainers taking care of the build
> status, and they are not afraid to revert. Also the build and test time is
> reasonable (while still being big), and individual developer can easily run
> all the tests on their machine before submitting patches. (Very few platform
> specific tests).
>
> On other projects I've seen on github with travis and co.: the tests are run
> for every pull request individually, before it is integrated. The reviewer
> sees the result of the tests and decide whether to merge on not based on the
> result. If one sees that the failures is obviously unrelated to the patch, the
> reviewer will override and merge anyway.
>
> I think this model could be easily applied to Qt.
>
> In particular, there should be an option to merge a patch directly without
> going through CI. (If you are scared of abuse, limit it to admin or
> maintainers).
> This could be used (exceptionally) for urgent patches such as patches that
> fixes the CI and that are not being integrated quickly enough because of other
> unrelated failures, continuing to block the CI for days. That way, the CI
> would not get in the way.
>
> In Summary: The CI should be a tool helping the development, and not slowing
> it down. And having a way to override the CI for important patches should be
> an easy and quick way to improve things a bit.

You seem to ignore that fact that CI is used to build final release binaries. 
So it
doesn't matter if you can merge patch bypassing CI or not, to get release you
have to pass through it.

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

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Olivier Goffart
Am Freitag, 9. Februar 2018, 08:13:01 CET schrieb Thiago Macieira:
> On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
> > IMHO, you need to rethink your whole CI approach. This is increasingly
> > being the one bottleneck slowing down Qt development and releases. It
> > might make more sense to try a different approach, such as allowing all
> > commits through initially, then making CI runs at regular intervals, and
> > triggering reverts if things broke.
> 
> Which will happen ALL the time. We'll never get back down: when we released
> Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only
> happened for QWS). For the other platforms, the normal number was a hundred
> tests failing. Then we spent weeks trying to get the number down.
>
> Sorry, I don't want to go back to that.

That's not exactly how I remember it from the Qt 4.6 and 4.7 times where there 
was no CI yet, but we were actively fixing tests. There were always a few red 
tests on testr.troll.no, but they were mostly flacky tests. What is it 
compared to now with about 100 BLACKLIST files in qtbase alone? (there was no 
blacklist at the time)
 
That said, I agree we should not go back to that.

> 
> > Qt is being developed very much as a corporate project. (I write "as"
> > rather than "like" because that's what Qt is, despite Open Governance.)
> > It would help to look at how community Free Software projects do things.
> > They tend to be more efficient. And some company-developed Free Software
> > projects have already adopted such processes.
> 
> It would not do us well to look at poorer practices than what we have. Just
> because everyone else is where we were 10 years ago is no reason for us to
> go back to it. Show us a *better* model, one that still prevents failures
> from being added, and we'll consider it.

How pretentious are you, thinking that everybody else has poorer practice?
Other projects still manage to release product with passing test. And might 
not get ludicrous release delay "because of the CI system" that was supposed 
to help, but gets in the way instead.

Anyway, here is some example of models which works:

In LLVM, devs commit directly. buildbots build the trunk continuously. In case 
of failure, the buildbot maintainer quickly find out which commit likely broke 
the test and reverts the commit imediatly (or commit a fix if the fix is 
trivial)
This works because there are buildbot maintainers taking care of the build 
status, and they are not afraid to revert. Also the build and test time is 
reasonable (while still being big), and individual developer can easily run 
all the tests on their machine before submitting patches. (Very few platform 
specific tests).

On other projects I've seen on github with travis and co.:  the tests are run 
for every pull request individually, before it is integrated. The reviewer 
sees the result of the tests and decide whether to merge on not based on the 
result. If one sees that the failures is obviously unrelated to the patch, the 
reviewer will override and merge anyway.

I think this model could be easily applied to Qt.

In particular, there should be an option to merge a patch directly without 
going through CI. (If you are scared of abuse, limit it to admin or 
maintainers).
This could be used (exceptionally) for urgent patches such as patches that 
fixes the CI and that are not being integrated quickly enough because of other 
unrelated failures, continuing to block the CI for days. That way, the CI 
would not get in the way.

In Summary: The CI should be a tool helping the development, and not slowing 
it down. And having a way to override the CI for important patches should be 
an easy and quick way to improve things a bit.

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-09 Thread Tuukka Turunen

On 09/02/2018, 9.51, "Development on behalf of Lars Knoll" 
 wrote:

   
> On 9 Feb 2018, at 08:13, Thiago Macieira  
wrote:
> 
> On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
>> IMHO, you need to rethink your whole CI approach. This is increasingly 
being
>> the one bottleneck slowing down Qt development and releases. It might 
make
>> more sense to try a different approach, such as allowing all commits
>> through initially, then making CI runs at regular intervals, and 
triggering
>> reverts if things broke.
> 
> Which will happen ALL the time. We'll never get back down: when we 
released Qt 
> 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only 
happened 
> for QWS). For the other platforms, the normal number was a hundred tests 
> failing. Then we spent weeks trying to get the number down.
> 
> Sorry, I don't want to go back to that.

I 100% agree with Thiago. We’ve been there, tried that and it didn’t work. 

Tuukka: Same here. We should continue to add automation and test coverage in 
different platforms, rather than reduce it. We need to get the infrastructure 
stability into shape and continue improving the test asset continuously.

> 
>> Qt is being developed very much as a corporate project. (I write "as" 
rather
>> than "like" because that's what Qt is, despite Open Governance.) It would
>> help to look at how community Free Software projects do things. They tend
>> to be more efficient. And some company-developed Free Software projects
>> have already adopted such processes.
> 
> It would not do us well to look at poorer practices than what we have. 
Just 
> because everyone else is where we were 10 years ago is no reason for us 
to go 
> back to it. Show us a *better* model, one that still prevents failures 
from 
> being added, and we'll consider it. 
> 
> The only one I know that fits the bill is the OpenStack model. Like Qt's, 
> staged commits get tested *before* they are added to the mainline. The 
> difference is that they have a massive datacenter, so they can run more 
> quickly. They have even enough spare capacity to bisect the commits being 
> added and figure out which one introduced the failure. We can't do that.

This is what we’re trying to fix by improving our CI capacity. I believe 
there are more things we need to do, but speeding up our turnaround time in CI 
is one of the most important things here. The rest is stability of the system 
and flaky tests. Both are things we need to work on.

Tuukka: Exactly. This is the first step, and it should help already 
significantly. In addition we need to solve the issues with multiple branches 
open, as discussed earlier. This probably needs some changes to the current 
practices, so that we can get the needed fixes faster to all branches. Capacity 
and stability need to be fixed first, but most likely are not enough. 


> 
>> Just my 2 cents as a (mostly) packager and application developer.
> 
> And my 2 cents as a core developer, maintainer, open source & community 
> expert, and someone who has followed the subject for the past 12 years.

Cheers,
Lars

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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Lars Knoll
> On 9 Feb 2018, at 07:52, Kevin Kofler  wrote:
> 
> André Pönitz wrote:
>> I think you need to start differentiating between Qt-without-Webengine
>> and QtWebengine.
>> 
>> And maybe "we" should do that, too.
> 
> I would be entirely in favor of separate (more frequent and/or more aligned 
> with Chromium security fixes) QtWebEngine releases. I am already updating 
> QtWebEngine in Fedora on a separate schedule from the core Qt updates (with 
> the intent of delivering security updates faster), so it would not be a 
> problem for me if the releases were entirely separate. And it would surely 
> get security fixes delivered in a more timely manner.

We’ve been discussing this in the past, and most people agreed that releasing 
QtWebEngine on an independent schedule would be a good thing. But there’s still 
a couple of things that need sorting out before that can happen, both in the CI 
and how we create/package our product and SDK as well as in QtWebengine which 
for example still uses private API of some other parts of Qt.

Cheers,
Lars

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Lars Knoll


> On 9 Feb 2018, at 08:13, Thiago Macieira  wrote:
> 
> On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
>> IMHO, you need to rethink your whole CI approach. This is increasingly being
>> the one bottleneck slowing down Qt development and releases. It might make
>> more sense to try a different approach, such as allowing all commits
>> through initially, then making CI runs at regular intervals, and triggering
>> reverts if things broke.
> 
> Which will happen ALL the time. We'll never get back down: when we released 
> Qt 
> 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only happened 
> for QWS). For the other platforms, the normal number was a hundred tests 
> failing. Then we spent weeks trying to get the number down.
> 
> Sorry, I don't want to go back to that.

I 100% agree with Thiago. We’ve been there, tried that and it didn’t work. 
> 
>> Qt is being developed very much as a corporate project. (I write "as" rather
>> than "like" because that's what Qt is, despite Open Governance.) It would
>> help to look at how community Free Software projects do things. They tend
>> to be more efficient. And some company-developed Free Software projects
>> have already adopted such processes.
> 
> It would not do us well to look at poorer practices than what we have. Just 
> because everyone else is where we were 10 years ago is no reason for us to go 
> back to it. Show us a *better* model, one that still prevents failures from 
> being added, and we'll consider it. 
> 
> The only one I know that fits the bill is the OpenStack model. Like Qt's, 
> staged commits get tested *before* they are added to the mainline. The 
> difference is that they have a massive datacenter, so they can run more 
> quickly. They have even enough spare capacity to bisect the commits being 
> added and figure out which one introduced the failure. We can't do that.

This is what we’re trying to fix by improving our CI capacity. I believe there 
are more things we need to do, but speeding up our turnaround time in CI is one 
of the most important things here. The rest is stability of the system and 
flaky tests. Both are things we need to work on.
> 
>> Just my 2 cents as a (mostly) packager and application developer.
> 
> And my 2 cents as a core developer, maintainer, open source & community 
> expert, and someone who has followed the subject for the past 12 years.

Cheers,
Lars

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Thiago Macieira
On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
> IMHO, you need to rethink your whole CI approach. This is increasingly being
> the one bottleneck slowing down Qt development and releases. It might make
> more sense to try a different approach, such as allowing all commits
> through initially, then making CI runs at regular intervals, and triggering
> reverts if things broke.

Which will happen ALL the time. We'll never get back down: when we released Qt 
4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only happened 
for QWS). For the other platforms, the normal number was a hundred tests 
failing. Then we spent weeks trying to get the number down.

Sorry, I don't want to go back to that.

> Qt is being developed very much as a corporate project. (I write "as" rather
> than "like" because that's what Qt is, despite Open Governance.) It would
> help to look at how community Free Software projects do things. They tend
> to be more efficient. And some company-developed Free Software projects
> have already adopted such processes.

It would not do us well to look at poorer practices than what we have. Just 
because everyone else is where we were 10 years ago is no reason for us to go 
back to it. Show us a *better* model, one that still prevents failures from 
being added, and we'll consider it. 

The only one I know that fits the bill is the OpenStack model. Like Qt's, 
staged commits get tested *before* they are added to the mainline. The 
difference is that they have a massive datacenter, so they can run more 
quickly. They have even enough spare capacity to bisect the commits being 
added and figure out which one introduced the failure. We can't do that.

> Just my 2 cents as a (mostly) packager and application developer.

And my 2 cents as a core developer, maintainer, open source & community 
expert, and someone who has followed the subject for the past 12 years.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Kevin Kofler
Lars Knoll wrote:
> One thing we’re doing currently is adding more capacity to CI. This has
> been a bottleneck that was slowing down merges and qt5.git updates. Better
> capacity should be in place in early spring.

(Disclaimer: The following proposal may sound "insane" to you. I also do not 
have any kind of decision power here in Qt. Still, I cannot resist the urge 
to formulate it.)

IMHO, you need to rethink your whole CI approach. This is increasingly being 
the one bottleneck slowing down Qt development and releases. It might make 
more sense to try a different approach, such as allowing all commits through 
initially, then making CI runs at regular intervals, and triggering reverts 
if things broke.

Qt is being developed very much as a corporate project. (I write "as" rather 
than "like" because that's what Qt is, despite Open Governance.) It would 
help to look at how community Free Software projects do things. They tend to 
be more efficient. And some company-developed Free Software projects have 
already adopted such processes.

Just my 2 cents as a (mostly) packager and application developer.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Kevin Kofler
André Pönitz wrote:
> I think you need to start differentiating between Qt-without-Webengine
> and QtWebengine.
> 
> And maybe "we" should do that, too.

I would be entirely in favor of separate (more frequent and/or more aligned 
with Chromium security fixes) QtWebEngine releases. I am already updating 
QtWebEngine in Fedora on a separate schedule from the core Qt updates (with 
the intent of delivering security updates faster), so it would not be a 
problem for me if the releases were entirely separate. And it would surely 
get security fixes delivered in a more timely manner.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread André Pönitz
On Thu, Feb 08, 2018 at 04:32:25AM +0100, Kevin Kofler wrote:
> Lars Knoll wrote:
> > * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s
> > branch now, create first alpha and then beta packages as quickly as
> > possible. Not having to merge from 5.10 will ease this significantly.
> > Getting 5.11 out quick will hopefully also make Webengine not fall too
> > far/long behind upstream security patches.
> 
> We are now in early February. By your schedule, 5.11 will be out on the last 
> day of May. That's a whopping 4 months without a Qt release from the current 
> (non-LTS) branch! In that time, at least 2 batches of Chromium security 
> updates will happen. And that does not even account for the inevitable slips 
> that consistently happen.
> 
> If this decision is now final, you are really telling your users to get 
> lost! :-(

I think you need to start differentiating between Qt-without-Webengine
and QtWebengine.

And maybe "we" should do that, too.

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Konstantin Tokarev


08.02.2018, 11:17, "Lars Knoll" :
>>  On 8 Feb 2018, at 08:35, Thiago Macieira  wrote:
>>
>>  On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote:
>>>  We are now in early February. By your schedule, 5.11 will be out on the 
>>> last
>>>  day of May. That's a whopping 4 months without a Qt release from the
>>>  current (non-LTS) branch! In that time, at least 2 batches of Chromium
>>>  security updates will happen. And that does not even account for the
>>>  inevitable slips that consistently happen.
>>
>>  I want to point out that we appeared to have fixed our release problems. The
>>  last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2.
>
> Yes, I think we have fixed most of the problems related to getting releases 
> out. What we haven’t yet fixed good enough is how to work with 5 open 
> branches at the same time. The cost of handling those is largely invisible to 
> those not doing the work, but it’s there. The merges from one branch to the 
> next plus updates to qt5.git are the main problem here. Those do cost a lot 
> of time and effort that go away from bug fixing and testing.
>
>>  But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, 
>> even
>>  5.9.3 was released before 5.10.0. This means we managed TWO releases between
>>  5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release
>>  5.9.5 and 5.10.2 before 5.11.0 if we wanted to.
>
> Most of the releases were done form 5.9, where we do not have a problem that 
> we need to merge changes from another branch. But getting 5.10 out was again 
> pretty painful due to the merges from 5.9. We often had very long times 
> between successful qt5.git updates. Having one additional branch with both 
> 5.10 and 5.11 and dev where we need to cascade merges will make that problem 
> quite a bit bigger.
>
> So we’re still not in the world I’d like to have where we can handle multiple 
> branches in a good way. This is something we need to try to solve and find 
> ways to handle better.
>
> One thing we’re doing currently is adding more capacity to CI. This has been 
> a bottleneck that was slowing down merges and qt5.git updates. Better 
> capacity should be in place in early spring.

Have you considered assigning priorities to CI jobs?

>
> The other thing I believe we need to do is to find ways to automate merges 
> between branches and do those one a more continuous basis. Currently we often 
> ended up waiting many days until a fix had been merged into all relevant 
> branches, leading to delays in different places. Ideally those merges should 
> happen daily, not once every two weeks.
>
> If required, we could probably still do a 5.10.2, but if we do it, I’d like 
> to limit that one to security issues, and avoid the long merge chain from 
> 5.10 to dev until we have figured out how to handle that better.
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Lars Knoll
> On 8 Feb 2018, at 08:35, Thiago Macieira  wrote:
> 
> On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote:
>> We are now in early February. By your schedule, 5.11 will be out on the last
>> day of May. That's a whopping 4 months without a Qt release from the
>> current (non-LTS) branch! In that time, at least 2 batches of Chromium
>> security updates will happen. And that does not even account for the
>> inevitable slips that consistently happen.
> 
> I want to point out that we appeared to have fixed our release problems. The 
> last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2.

Yes, I think we have fixed most of the problems related to getting releases 
out. What we haven’t yet fixed good enough is how to work with 5 open branches 
at the same time. The cost of handling those is largely invisible to those not 
doing the work, but it’s there. The merges from one branch to the next plus 
updates to qt5.git are the main problem here. Those do cost a lot of time and 
effort that go away from bug fixing and testing.

> 
> But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even 
> 5.9.3 was released before 5.10.0. This means we managed TWO releases between 
> 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release 
> 5.9.5 and 5.10.2 before 5.11.0 if we wanted to.

Most of the releases were done form 5.9, where we do not have a problem that we 
need to merge changes from another branch. But getting 5.10 out was again 
pretty painful due to the merges from 5.9. We often had very long times between 
successful qt5.git updates. Having one additional branch with both 5.10 and 
5.11 and dev where we need to cascade merges will make that problem quite a bit 
bigger. 

So we’re still not in the world I’d like to have where we can handle multiple 
branches in a good way. This is something we need to try to solve and find ways 
to handle better. 

One thing we’re doing currently is adding more capacity to CI. This has been a 
bottleneck that was slowing down merges and qt5.git updates. Better capacity 
should be in place in early spring. 

The other thing I believe we need to do is to find ways to automate merges 
between branches and do those one a more continuous basis. Currently we often 
ended up waiting many days until a fix had been merged into all relevant 
branches, leading to delays in different places. Ideally those merges should 
happen daily, not once every two weeks.

If required, we could probably still do a 5.10.2, but if we do it, I’d like to 
limit that one to security issues, and avoid the long merge chain from 5.10 to 
dev until we have figured out how to handle that better.

Cheers,
Lars

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-08 Thread Lars Knoll
> On 8 Feb 2018, at 08:35, Thiago Macieira  wrote:
> 
> On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote:
>> We are now in early February. By your schedule, 5.11 will be out on the last
>> day of May. That's a whopping 4 months without a Qt release from the
>> current (non-LTS) branch! In that time, at least 2 batches of Chromium
>> security updates will happen. And that does not even account for the
>> inevitable slips that consistently happen.
> 
> I want to point out that we appeared to have fixed our release problems. The 
> last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2.

Yes, I think we have fixed most of the problems related to getting releases 
out. What we haven’t yet fixed good enough is how to work with 5 open branches 
at the same time. The cost of handling those is largely invisible to those not 
doing the work, but it’s there. The merges from one branch to the next plus 
updates to qt5.git are the main problem here. Those do cost a lot of time and 
effort that go away from bug fixing and testing.

> 
> But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even 
> 5.9.3 was released before 5.10.0. This means we managed TWO releases between 
> 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release 
> 5.9.5 and 5.10.2 before 5.11.0 if we wanted to.

Most of the releases were done form 5.9, where we do not have a problem that we 
need to merge changes from another branch. But getting 5.10 out was again 
pretty painful due to the merges from 5.9. We often had very long times between 
successful qt5.git updates. Having one additional branch with both 5.10 and 
5.11 and dev where we need to cascade merges will make that problem quite a bit 
bigger. 

So we’re still not in the world I’d like to have where we can handle multiple 
branches in a good way. This is something we need to try to solve and find ways 
to handle better. 

One thing we’re doing currently is adding more capacity to CI. This has been a 
bottleneck that was slowing down merges and qt5.git updates. Better capacity 
should be in place in early spring. 

The other thing I believe we need to do is to find ways to automate merges 
between branches and do those one a more continuous basis. Currently we often 
ended up waiting many days until a fix had been merged into all relevant 
branches, leading to delays in different places. Ideally those merges should 
happen daily, not once every two weeks.

If required, we could probably still do a 5.10.2, but if we do it, I’d like to 
limit that one to security issues, and avoid the long merge chain from 5.10 to 
dev until we have figured out how to handle that better.

Cheers,
Lars

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-07 Thread Thiago Macieira
On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote:
> We are now in early February. By your schedule, 5.11 will be out on the last
> day of May. That's a whopping 4 months without a Qt release from the
> current (non-LTS) branch! In that time, at least 2 batches of Chromium
> security updates will happen. And that does not even account for the
> inevitable slips that consistently happen.

I want to point out that we appeared to have fixed our release problems. The 
last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2.

But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even 
5.9.3 was released before 5.10.0. This means we managed TWO releases between 
5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release 
5.9.5 and 5.10.2 before 5.11.0 if we wanted to.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-07 Thread Kevin Kofler
Lars Knoll wrote:
> * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s
> branch now, create first alpha and then beta packages as quickly as
> possible. Not having to merge from 5.10 will ease this significantly.
> Getting 5.11 out quick will hopefully also make Webengine not fall too
> far/long behind upstream security patches.

We are now in early February. By your schedule, 5.11 will be out on the last 
day of May. That's a whopping 4 months without a Qt release from the current 
(non-LTS) branch! In that time, at least 2 batches of Chromium security 
updates will happen. And that does not even account for the inevitable slips 
that consistently happen.

If this decision is now final, you are really telling your users to get 
lost! :-(

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Jani Heikkinen
Hi,

So the decision how to proceed is done. Let's give everyone a while to finalize 
ongoing tasks and put the decision in effect after a week. 

So from 12.2.2018 ->
   - '5.9' will be in cherry-pick mode
   - '5.10' will be closed

We will make sure final merges from '5.9' -> '5.10' -> '5.11' will be done 
after that and then there will be merges only from '5.11' -> 'dev'

br,
Jani

From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> on 
behalf of Lars Knoll <lars.kn...@qt.io>
Sent: Monday, February 5, 2018 12:35 PM
To: Qt development mailing list
Subject: Re: [Development] Qt branches & proposal how to continue with those

Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it.
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen <oswald.buddenha...@qt.io> wrote:
>
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>>
> right.
>
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already.
>>
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
>
> this leaves us with three options:
> 1)
> - 5.9 goes to cherry-pick mode, essentially now.
> - 5.10 stays open until 5.11.0 is released.
>   - we should create 5.10.2 before the 5.11.0 release even if we don't
> intent to actually make a release, just so we have a mergable
> target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
> cherry-picks).
> 2)
> - we just declare that there won't be 5.10.2 and close 5.10 after
>   5.10.1. potentially not user-friendly, but we've done it in the
>   past, and while releasing capacity isn't the limiting factor now,
>   forward-merging apparently is.
> 2a) we continue to forward-merge from 5.9.
> 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
>
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
>
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Lars Knoll
Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it. 
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen  wrote:
> 
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>> 
> right.
> 
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already. 
>> 
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
> 
> this leaves us with three options:
> 1)
> - 5.9 goes to cherry-pick mode, essentially now.
> - 5.10 stays open until 5.11.0 is released.
>   - we should create 5.10.2 before the 5.11.0 release even if we don't
> intent to actually make a release, just so we have a mergable
> target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
> cherry-picks).
> 2)
> - we just declare that there won't be 5.10.2 and close 5.10 after
>   5.10.1. potentially not user-friendly, but we've done it in the
>   past, and while releasing capacity isn't the limiting factor now,
>   forward-merging apparently is.
> 2a) we continue to forward-merge from 5.9.
> 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
> 
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
> 
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Lars Knoll
Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it. 
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen  wrote:
> 
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>> 
> right.
> 
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already. 
>> 
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
> 
> this leaves us with three options:
> 1)
>  - 5.9 goes to cherry-pick mode, essentially now.
>  - 5.10 stays open until 5.11.0 is released.
>- we should create 5.10.2 before the 5.11.0 release even if we don't
>  intent to actually make a release, just so we have a mergable
>  target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
>  cherry-picks).
> 2)
>  - we just declare that there won't be 5.10.2 and close 5.10 after
>5.10.1. potentially not user-friendly, but we've done it in the
>past, and while releasing capacity isn't the limiting factor now,
>forward-merging apparently is.
>  2a) we continue to forward-merge from 5.9.
>  2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
> 
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
> 
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-02 Thread Allan Sandfeld Jensen
On Montag, 29. Januar 2018 14:40:20 CET Kevin Kofler wrote:
> Giuseppe D'Angelo wrote:
> > I don't agree, 5.10 releases should be done on a regular basis until
> > 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...)
> 
> +1, I also agree with you and therefore disagree with the original proposal.
> 
> Especially security warrants always having one current release branch
> active. There is one Qt component (QtWebEngine) for which it is essentially
> GUARANTEED that there will be security concerns to address. In addition,
> security issues can hit any Qt component at any time. Those MUST be
> addressed in a timely manner for Qt to be usable.
> 
> While offering security fixes as patches attached to security advisories can
> work for some components, this is not always workable. In particular,
> QtWebEngine just cannot be handled that way.
> 
> And of course, there can also be other bugs that users will want fixed
> sooner rather than later.
> 
I also agree. We should have a patch release at least every two months. As far 
as can tell that should mean a 5.10.2.

'Allan


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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-02 Thread Edward Welbourne
Tuukka Turunen (1 February 2018 16:22)
> I think keeping 5.9 open a bit longer has benefit due to it being an
> LTS.

The benefit looks small, to me.

If I have to cherry-pick back to LTS, it's for an important issue; I've
just done that for QTBUG-66076 because it got reported against 5.9.4,
after I'd fixed it on dev (it made it into 5.10.0).  Maybe it's because
I can see bugs in code without needing a bug report to lead me to them,
but I'm used to this happening - I don't always know, when I'm fixing an
issue, whether it's important enough to warrant starting out in 5.9; and
I'm conservative enough to not put fixes into LTS unless I positively
see a definite need for them (e.g. an actual bug report).  Furthermore,
a fix cherry-picked back to LTS has the virtue of having seen relatively
thorough testing in other branches, reducing the risk of "surprises".

Having 5.9 at the start of the merge-chain incurs some hassle for anyone
who does end up needing to cherry-pick back to it, and may incur
conflicts during merge-up when that's happened; which encourages folk to
put changes into 5.9, just to be on the "safe" side (i.e. avoid that
hassle), when the fix might not actually be critical enough to belong
there - which isn't so good for the "safety" of LTS; every fix incurs a
risk of breakage; if that fix wasn't really needed in LTS, then this is
needless risk.  Furthermore, fixes introduced in 5.9, for merging up to
other branches, haven't been as rigorously tested as fixes that have
been round the grind in a later branch - which can discover unexpected
side-effects, that a fix developed on 5.9 will have introduced in LTS.

So you get a little convenience out of keeping 5.9 in the merge chain,
which I can see the virtue of up until about the point where 5.10.0 got
released, but that convenience comes at the price of added hassle for
those whose fixes on other branches turn out to be needed in LTS, plus a
bunch of added risk to the stability of LTS.

> It adds a bit merge effort, but should be manageable if 5.10 is out of
> the picture. We should aim to increase stability, as is the target of
> strict mode. Perhaps we could simple agree to now on push only items
> that match strict mode criteria to 5.9, rest goes to 5.11 or dev? Move
> to cherry pick mode for 5.9 a few months later then.

I get twitchy about the merge pattern being 5.9 -> 5.11 -> dev, without
passing through 5.10 on the way.  It'll lead to folk expecting things to
be in 5.10 when they aren't.  Once 5.10 is no longer part of the merge
chain, 5.9 should be in cherry-pick mode.  That change will make folk
more aware that their changes to 5.9 aren't getting into a putative
5.10.2, if it ever is needed, so there's a better chance they'll
evaluate whether it's needed there and, if it is, cherry-pick it to 5.10
ready for that (or fix it on 5.10 in the first place, if it stays in the
merge chain).

If we're going to stop merging up from 5.10, after 5.10.1 branches, then
we should switch 5.9 to cherry-picking mode at the same time; and allow
cherry-picks back to 5.10 for critical issues, targeting a 5.10.2 that
we hope we won't need but should be ready to produce if we do.

However, see Kevin's point: we *know* we'll have security fixes for
qtwebengine; our plan *should* take account of that.  Shall 5.11 and
5.11.1 be close enough to 5.10 that those on 5.10 can sensibly be
expected to upgrade to them - in which case, why aren't they called
5.10.2 and so on ? - or do we need to plan a 5.10.2 simply for
qtwebengine's sake ?  Or is it time we genuinely separated qtwebengine's
release schedule from the rest of Qt ?  Would that even work ?

We've upped the tempo of releases: this is, of course, good - but it
comes with costs.  When I'm fixing a bug, I fix it on dev and wait for
it to be reviewed before worrying about which branch it belongs on -
because, all too often, the branch I *would* have put it on at the start
has been released before anyone reviews what I've changed.  So I leave
that decision until I know which branch is appropriate *when the fix
gets past review* - but that tends to bias me towards putting it on a
later branch than it might have belonged on.

Pause to consider another model: we close 5.10 transiently, during the
life-time of 5.10.1, so that 5.10.1 takes 5.10's place in the merge
chain; we re-open 5.10 after 5.10.1 releases, only for critical fixes
that would be needed for a 5.10.2 release, if we can't avoid one.  When
5.10.1 closes, we'd do a merge from it to 5.10, which would then
re-open; then we merge up from there.  We would seldom need to merge up
from 5.10, reducing its contribution to the merge chain; and taking it
out of the chain during 5.10.1's stabilisation period makes sense.

As long as we put 5.9 into cherry-pick mode during that, we'll have a
merge chain that looks like:
  5.10.1 -> 5.11.0 -> 5.11 -> dev
and changes to
  5.10 -> 5.11.0 -> 5.11 -> dev
before reducing to
  5.10 -> 5.11 -> dev
with the 5.10 -> steps 

Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Kevin Kofler
Tuukka Turunen wrote:
> Of those 2a and 2b sound the best to me, however we should be able to make
> 5.10.2 at least in case needed on top of 5.10.1 with a critical security
> fix (or similar).

You are talking about needing maybe one security fix. I can tell you that it 
is practically certain that there will be several security fixes needed for 
QtWebEngine approx. every 6 weeks (at every Chromium release).

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Tuukka Turunen

Hi,

Of those 2a and 2b sound the best to me, however we should be able to make 
5.10.2 at least in case needed on top of 5.10.1 with a critical security fix 
(or similar).

I think keeping 5.9 open a bit longer has benefit due to it being an LTS. It 
adds a bit merge effort, but should be manageable if 5.10 is out of the 
picture. We should aim to increase stability, as is the target of strict mode. 
Perhaps we could simple agree to now on push only items that match strict mode 
criteria to 5.9, rest goes to 5.11 or dev? Move to cherry pick mode for 5.9 a 
few months later then.

Yours,

Tuukka

On 01/02/2018, 16.53, "Development on behalf of Oswald Buddenhagen" 
 wrote:

On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
> So based on this Qt 5.9 should be in cherry pick mode next week. With
> previous wording it should have been in cherry pick mode from 2.9.2017
> onwards, which was way too soon (hence the change to QUIP5).
> 
right.

> What about Qt 5.10.2? This of course needs to be addressed after we
> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
> release, I would like to put full focus into getting Qt 5.11.0 out
> quickly and try to release Qt 5.11.1 in June already. 
> 
yes, but the point is that we can't change the policy retroactively. if
5.10.2 is an option, then 5.10 needs to stay open as the default target
for fixes, and be forward-merged. this leaves us at two merges for a fix
to reach dev.
the same delay would occurr if we closed 5.10 and continued to merge
from 5.9, which is why the discussion which one is more important
emerged.

this leaves us with three options:
1)
  - 5.9 goes to cherry-pick mode, essentially now.
  - 5.10 stays open until 5.11.0 is released.
- we should create 5.10.2 before the 5.11.0 release even if we don't
  intent to actually make a release, just so we have a mergable
  target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
  cherry-picks).
2)
  - we just declare that there won't be 5.10.2 and close 5.10 after
5.10.1. potentially not user-friendly, but we've done it in the
past, and while releasing capacity isn't the limiting factor now,
forward-merging apparently is.
  2a) we continue to forward-merge from 5.9.
  2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.

note that 5.10 going to cherry-pick mode is specifically not an option,
as stated previously.

1) seems most natural to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Oswald Buddenhagen
On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
> So based on this Qt 5.9 should be in cherry pick mode next week. With
> previous wording it should have been in cherry pick mode from 2.9.2017
> onwards, which was way too soon (hence the change to QUIP5).
> 
right.

> What about Qt 5.10.2? This of course needs to be addressed after we
> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
> release, I would like to put full focus into getting Qt 5.11.0 out
> quickly and try to release Qt 5.11.1 in June already. 
> 
yes, but the point is that we can't change the policy retroactively. if
5.10.2 is an option, then 5.10 needs to stay open as the default target
for fixes, and be forward-merged. this leaves us at two merges for a fix
to reach dev.
the same delay would occurr if we closed 5.10 and continued to merge
from 5.9, which is why the discussion which one is more important
emerged.

this leaves us with three options:
1)
  - 5.9 goes to cherry-pick mode, essentially now.
  - 5.10 stays open until 5.11.0 is released.
- we should create 5.10.2 before the 5.11.0 release even if we don't
  intent to actually make a release, just so we have a mergable
  target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
  cherry-picks).
2)
  - we just declare that there won't be 5.10.2 and close 5.10 after
5.10.1. potentially not user-friendly, but we've done it in the
past, and while releasing capacity isn't the limiting factor now,
forward-merging apparently is.
  2a) we continue to forward-merge from 5.9.
  2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.

note that 5.10 going to cherry-pick mode is specifically not an option,
as stated previously.

1) seems most natural to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Tuukka Turunen

Hi,

To be clear, the updated QUIP5 
(http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst) says: 

"*strict*
This period starts when the one after next stable branch is created (for the
5.9 LTS, the one after next is 5.11). Submitting to the LTS branch directly
is then no longer possible; changes must be submitted to the stable branch
and undergo some testing first before being cherry-picked into the LTS
branch."

So based on this Qt 5.9 should be in cherry pick mode next week. With previous 
wording it should have been in cherry pick mode from 2.9.2017 onwards, which 
was way too soon (hence the change to QUIP5).

I think that it is not possible to wait until Qt 5.11.0 is released before 
going to cherry pick mode for Qt 5.9 LTS and closing (or moving to cherry pick 
mode) for Qt 5.10. We just do not have enough people and computers to manage 
all the needed merges in time.  I do understand the opinions that it would be 
nice to have these open longer, but it is not seen feasible by the persons who 
actually do the work needed for it. 

Related to LTS releases in general, I believe that strict mode is a good thing. 
By only cherry picking the important fixes, we reduce the risk of accidentally 
causing some undesired regressions (in functionality or performance). We do 
want to continue making more Qt 5.9.x patch level releases, but with slightly 
reduced pace after Qt 5.9.5 (planned for March).  

I believe that we can achieve two important items by reducing the amount of 
merges (Jani's original proposal):
1. Release Qt 5.11 in schedule without a huge stress for the release 
team at the end
2. Keep dev in good working shape during H1/18, thus paving the way of 
having a rock solid Qt 5.12 (LTS) in November

What about Qt 5.10.2? This of course needs to be addressed after we see how Qt 
5.10.1 turns out to be. But provided Qt 5.10.1 is a good release, I would like 
to put full focus into getting Qt 5.11.0 out quickly and try to release Qt 
5.11.1 in June already. 

Yours,

Tuukka

On 01/02/2018, 13.36, "Development on behalf of Konstantin Tokarev" 
 wrote:



01.02.2018, 14:19, "Oswald Buddenhagen" :
> On Tue, Jan 30, 2018 at 09:38:29PM +, Tuukka Turunen wrote:
>>  The item that has received comments both in favor and against is what
>>  to do with 5.10 now. I think that instead of closing 5.10, we could
>>  move it to cherry pick mode, just like Qt 5.9 is. That allows putting
>>  the necessary fixes there, but reduces the amount of needed merges a
>>  lot. It also allows to faster get all the fixes merged up to dev,
>>  which is something we have struggled in the past.
>
> that makes no sense at all.
> firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5
> codifies this status quo. i see no reason to revise that decision
> *again*.
> secondly, *nobody* is going to cherry-pick to a branch which *could*
> _hypothetically_ have another patch release, because that would be an
> epic waste of resources.
> thirdly, let me point out that cherry-picking *delays* patch releases,
> because it implies that a commit must have already integrated into a
> more current branch before it can hit the release branch (deviating from
> that principle is just plain stupid), which in the context of our
> infrastructure makes it a poor choice for recent/active branches.

Only in case when cherry-picked patches are release blockers, otherwise
they just don't go in if they miss schedule.

I guess the idea behind this proposal is that we improve quality of dev and
5.11 by sacrificing comprehensiveness of 5.6, 5.9, and 5.10. Multi-level
merges combined with overall CI instability lead to huge delays for patches
to reach dev, as a result people work on stable branches or maintain their
own, which in turn leaves us with worse baseline when next releases' branch
is started from dev.

>
> so no, this just isn't an option.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Konstantin Tokarev


01.02.2018, 14:19, "Oswald Buddenhagen" :
> On Tue, Jan 30, 2018 at 09:38:29PM +, Tuukka Turunen wrote:
>>  The item that has received comments both in favor and against is what
>>  to do with 5.10 now. I think that instead of closing 5.10, we could
>>  move it to cherry pick mode, just like Qt 5.9 is. That allows putting
>>  the necessary fixes there, but reduces the amount of needed merges a
>>  lot. It also allows to faster get all the fixes merged up to dev,
>>  which is something we have struggled in the past.
>
> that makes no sense at all.
> firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5
> codifies this status quo. i see no reason to revise that decision
> *again*.
> secondly, *nobody* is going to cherry-pick to a branch which *could*
> _hypothetically_ have another patch release, because that would be an
> epic waste of resources.
> thirdly, let me point out that cherry-picking *delays* patch releases,
> because it implies that a commit must have already integrated into a
> more current branch before it can hit the release branch (deviating from
> that principle is just plain stupid), which in the context of our
> infrastructure makes it a poor choice for recent/active branches.

Only in case when cherry-picked patches are release blockers, otherwise
they just don't go in if they miss schedule.

I guess the idea behind this proposal is that we improve quality of dev and
5.11 by sacrificing comprehensiveness of 5.6, 5.9, and 5.10. Multi-level
merges combined with overall CI instability lead to huge delays for patches
to reach dev, as a result people work on stable branches or maintain their
own, which in turn leaves us with worse baseline when next releases' branch
is started from dev.

>
> so no, this just isn't an option.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Oswald Buddenhagen
On Tue, Jan 30, 2018 at 09:38:29PM +, Tuukka Turunen wrote:
> The item that has received comments both in favor and against is what
> to do with 5.10 now. I think that instead of closing 5.10, we could
> move it to cherry pick mode, just like Qt 5.9 is. That allows putting
> the necessary fixes there, but reduces the amount of needed merges a
> lot. It also allows to faster get all the fixes merged up to dev,
> which is something we have struggled in the past.
> 
that makes no sense at all.
firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5
codifies this status quo. i see no reason to revise that decision
*again*.
secondly, *nobody* is going to cherry-pick to a branch which *could*
_hypothetically_ have another patch release, because that would be an
epic waste of resources.
thirdly, let me point out that cherry-picking *delays* patch releases,
because it implies that a commit must have already integrated into a
more current branch before it can hit the release branch (deviating from
that principle is just plain stupid), which in the context of our
infrastructure makes it a poor choice for recent/active branches.

so no, this just isn't an option.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Sean Harmer
-1 from me. How is this any less work than merging, especially with git 
rerere?


Can we please keep 5.9 open until we have at least released 5.11.0?

I really don't want to get into a situation where we have bug fixes on 
5.9 and 5.11 but not 5.10.2 say.


Once 5.10 is properly closed then fine, move to a cherry pick approach 
for 5.9 but right now, especially for Qt 3D we have some important bug 
fixes landing on 5.9 than can be merged forward (with the help of git 
rerere) but for which cherry picking would be more awkward and also risk 
missing 5.10.2 if there is one.


Cheers,

Sean

On 01/02/2018 10:21, Jani Heikkinen wrote:

-Original Message-
From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
project.org] On Behalf Of Tuukka Turunen
Sent: tiistai 30. tammikuuta 2018 23.38
To: Konrad Rosenbaum <kon...@silmor.de>; development@qt-project.org
Subject: Re: [Development] Qt branches & proposal how to continue with those

The item that has received comments both in favor and against is what to do
with 5.10 now. I think that instead of closing 5.10, we could move it to cherry
pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, 
but
reduces the amount of needed merges a lot. It also allows to faster get all the
fixes merged up to dev, which is something we have struggled in the past.

With this approach we have full capability to make Qt 5.10.2 release, if one is
needed. We also continue to make Qt 5.9.x patch releases. We would have two
branches open for direct submission: 5.11 and dev, and for each commit the
lowest applicable branch can be chosen. For all such important fixes that need
to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking.



This is OK for me as well so +1 from my side

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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-02-01 Thread Jani Heikkinen
> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Tuukka Turunen
> Sent: tiistai 30. tammikuuta 2018 23.38
> To: Konrad Rosenbaum <kon...@silmor.de>; development@qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
> 
> The item that has received comments both in favor and against is what to do
> with 5.10 now. I think that instead of closing 5.10, we could move it to 
> cherry
> pick mode, just like Qt 5.9 is. That allows putting the necessary fixes 
> there, but
> reduces the amount of needed merges a lot. It also allows to faster get all 
> the
> fixes merged up to dev, which is something we have struggled in the past.
> 
> With this approach we have full capability to make Qt 5.10.2 release, if one 
> is
> needed. We also continue to make Qt 5.9.x patch releases. We would have two
> branches open for direct submission: 5.11 and dev, and for each commit the
> lowest applicable branch can be chosen. For all such important fixes that need
> to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking.
> 

This is OK for me as well so +1 from my side

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-30 Thread Kevin Kofler
Jani Heikkinen wrote:
> I have to disagree there: We have already released 4 patch level releases
> for LTS 5.9 so it is actually moving quite fast.

That is not what I meant with fast-moving! Those LTS patch releases by 
design do not provide the new features that the releases from higher 
branches provide. When I write "fast-moving distribution", I mean a 
distribution that focuses on getting features to its users as quickly as 
possible, as opposed to the conservative "enterprise" distributions that are 
the ones actually interested in LTS branches of upstream software.

And even when it comes to bug (and security!) fixes, for how long are you 
going to keep up this pace of 5.9.x releases? In the previous LTS series, 
there was almost a whole year between 5.6.2 and 5.6.3. QtWebEngine CVEs kept 
piling up in that time.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-30 Thread Tuukka Turunen

Hi,

What Keven wrote below is absolutely true. Within the one million users of Qt 
we really have an extremely wide variety of different needs. 
 
Also in this discussion, there has been quite a versatile set of opinions 
stated, which is very good. There has been some suggestions to even not make 
patch releases at all for non-LTS releases (which is way more scarce on 
releases that Jani initially suggested). There has been some discussion about 
which is more important to have patch releases for: LTS or non-LTS versions. 
Luckily we are not in a situation where we would have to choose. Both are 
important and it is very natural that an LTS will receive more patch level 
releases than a non-LTS release.

Here is what Jani originally proposed (to happen starting from 1st Feb 2018):

- '5.6' will move in 'very strict' mode
- '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
cherry picks from stable
- '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
long)
- '5.11' will be to one and only stable branch

The item that has received comments both in favor and against is what to do 
with 5.10 now. I think that instead of closing 5.10, we could move it to cherry 
pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, 
but reduces the amount of needed merges a lot. It also allows to faster get all 
the fixes merged up to dev, which is something we have struggled in the past.

With this approach we have full capability to make Qt 5.10.2 release, if one is 
needed. We also continue to make Qt 5.9.x patch releases. We would have two 
branches open for direct submission: 5.11 and dev, and for each commit the 
lowest applicable branch can be chosen. For all such important fixes that need 
to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking. 

Yours,

Tuukka

On 30/01/2018, 12.27, "Development on behalf of Konrad Rosenbaum" 
 wrote:

On Tue, January 30, 2018 00:18, Kevin Kofler wrote:
> I would on the contrary expect users to want new features sooner rather
> than
> later,
[...]

Please keep in mind that there are several classes of Qt users:

Mobile: moving fast and furious. Depend on novelty.

General Desktop: moving somewhat fast. Prefer novelty.

Offices w/ IT admins: move much slower. Prefer stability over novelty.

Industrial, regulated and embedded: move extremely slow. Depend on 
stability.

I've been in projects that jumped ship every time someone invented a new
buzz word and in projects where I had to compile my own GCC and X11
libraries because no supported version of Qt would compile with the one(s)
in the target OS.



 Konrad

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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-30 Thread Konrad Rosenbaum
On Tue, January 30, 2018 00:18, Kevin Kofler wrote:
> I would on the contrary expect users to want new features sooner rather
> than
> later,
[...]

Please keep in mind that there are several classes of Qt users:

Mobile: moving fast and furious. Depend on novelty.

General Desktop: moving somewhat fast. Prefer novelty.

Offices w/ IT admins: move much slower. Prefer stability over novelty.

Industrial, regulated and embedded: move extremely slow. Depend on stability.

I've been in projects that jumped ship every time someone invented a new
buzz word and in projects where I had to compile my own GCC and X11
libraries because no supported version of Qt would compile with the one(s)
in the target OS.



 Konrad

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Jani Heikkinen
> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Kevin Kofler
> Sent: maanantai 29. tammikuuta 2018 15.33
> To: development@qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
> 
> Simon Hausmann wrote:
> > In the light of that, I think it would be better to keep the LTS
> > branches open longer and stop doing patch releases for minor releases
> > that are not LTS.
> 
> -1 from a distro packager perspective. LTS just does not fit together with 
> fast-
> moving distributions, and we really need those bugfix releases for the 
> branches
> we ship.

I have to disagree there: We have already released 4 patch level releases for 
LTS 5.9 so it is actually moving quite fast.

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Thiago Macieira
On segunda-feira, 29 de janeiro de 2018 21:57:38 PST Tuukka Turunen wrote:
> Hi,
> 
> This is not an either-or thing. Of course both having new feature releases
> and stable LTS are important. I am not claiming otherwise. My point is that
> there are more users for the LTS versions, thus I used the expression.

And that's exactly what Kevin objected: you don't present any data to say that 
there are more for LTS compared to others. All we know is that there are users 
for both and we also know that there are some users who cannot upgrade because 
we dropped platforms in both 5.10 an 5.11.

> I still would like to emphasize the point I made in my e-mail: this is to me
> specifically about what do we do to Qt 5.10 branch after release of Qt
> 5.10.1. Not about stopping patch releases altogether for other than LTS. 

My opinion is: we continue it until at least 5.11.0.

I understand that there are a lot of branches, but most of them have little to 
no activity:

qtbase $ git rev-list --count --since=6.months.ago origin/5.6
21
qtbase $ git rev-list --count --since=3.months.ago origin/5.6
7
qtdeclarative $ git rev-list --count --since=6.months.ago origin/5.6
8
qtdeclarative $ git rev-list --count --since=3.months.ago origin/5.6
1

All of Qt 5.6 has 44 commits total for the last 6 months, 8 in the last three. 
That also means only two repositories in 5.6 changed in the last three months: 
qtbase and qtdeclarative. The time between the last and the second-to-last 
commits in qtbase was over a month.

So at this point 5.6 basically doesn't count. So we effectively have open 5.9, 
5.10, 5.11 and dev, which is the same quantity as just after the 5.8 branching 
(5.6, 5.7, 5.8 and dev). And that's exactly what led to the worst release of 
all: 5.8.0. Let's not repeat that mistake.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Tuukka Turunen

Hi,

This is not an either-or thing. Of course both having new feature releases and 
stable LTS are important. I am not claiming otherwise. My point is that there 
are more users for the LTS versions, thus I used the expression. There are a 
lot of users for both, we do not need to have a poll to know that these are 
both important. 

I still would like to emphasize the point I made in my e-mail: this is to me 
specifically about what do we do to Qt 5.10 branch after release of Qt 5.10.1. 
Not about stopping patch releases altogether for other than LTS. 

Yours,

Tuukka

On 30/01/2018, 1.19, "Development on behalf of Kevin Kofler" 
 wrote:

Tuukka Turunen wrote:
> Users prefer LTS releases

According to what statistics? Also keep in mind that distributions will 
download Qt once and redistribute it to thousands of users. And also that 
there are 2 classes of Qt users: application developers and end users.

Such a bold claim really ought to be more substantiated than that.

I would on the contrary expect users to want new features sooner rather 
than 
later, also considering that Qt is almost 100% backwards compatible from 
one 
release to the next anyway, but that is just a feeling with no statistics 
at 
all.

Kevin Kofler

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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Kevin Kofler
Tuukka Turunen wrote:
> Users prefer LTS releases

According to what statistics? Also keep in mind that distributions will 
download Qt once and redistribute it to thousands of users. And also that 
there are 2 classes of Qt users: application developers and end users.

Such a bold claim really ought to be more substantiated than that.

I would on the contrary expect users to want new features sooner rather than 
later, also considering that Qt is almost 100% backwards compatible from one 
release to the next anyway, but that is just a feeling with no statistics at 
all.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Tuukka Turunen

Hi,

To comment a bit this discussion, I think that with Qt 5.10 as the first 
release after the LTS it might be fine to stop after .1, but in general I would 
not want to set such a rule. To me the question at hand is should we skip Qt 
5.10.2 release if that means we can put more fixes into Qt 5.9.x and manage to 
release Qt 5.11 in time? As Jani pointed out the challenge is number of stable 
branches and the needed amount of merges. Users prefer LTS releases, so 
focusing the effort to have more bug fixes and patch releases for the LTS 
release rather than the LTS+1 release benefits a higher amount of users than 
the other way around. That said, we should not continue to push majority of 
fixes to Qt 5.9 too long as that is also counterproductive for the need to have 
a rock solid LTS release.

Yours,

Tuukka

On 29/01/2018, 18.11, "Development on behalf of Thiago Macieira" 
 wrote:

On segunda-feira, 29 de janeiro de 2018 04:10:02 PST Adam Treat wrote:
> “stop doing patch releases for minor releases that are not LTS.”
> 
> +1

So long as we "stop after the .1" 

Just look at how many distributions skipped 5.8 entirely because it didn't 
have a .1. That was a huge mistake on our part.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Kevin Kofler
Konstantin Tokarev wrote:
> Note that you can build newer QtWebEngine releases against LTS Qt

I know, and I am already doing this, but this does not help if there is no 
newer QtWebEngine release to begin with! Even taking a snapshot is typically 
not an option because security fixes are only backported in batches when a 
release is imminent (and in any case, will never be backported to a closed 
release branch).

If QtWebEngine releases actually get decoupled from Qt releases, that could 
address this issue, but as things are now, the Qt bugfix releases are needed 
for QtWebEngine.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Thiago Macieira
On segunda-feira, 29 de janeiro de 2018 04:10:02 PST Adam Treat wrote:
> “stop doing patch releases for minor releases that are not LTS.”
> 
> +1

So long as we "stop after the .1" 

Just look at how many distributions skipped 5.8 entirely because it didn't 
have a .1. That was a huge mistake on our part.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Konstantin Tokarev


29.01.2018, 16:33, "Kevin Kofler" :
> Simon Hausmann wrote:
>>  In the light of that, I think it would be better to keep the LTS branches
>>  open longer and stop doing patch releases for minor releases that are not
>>  LTS.
>
> -1 from a distro packager perspective. LTS just does not fit together with
> fast-moving distributions, and we really need those bugfix releases for the
> branches we ship.
>
> Especially QtWebEngine requires those bugfix releases for security fixes,
> and tracking LTS is not that great there because the base Chromium gets old
> pretty quickly, and websites start complaining (e.g., Google already
> complains about 5.9 being an outdated Chromium) or even stop working
> altogether. The frequency of LTS releases has also so far been totally
> insufficient to keep up with Chromium security fixes (see the huge amount of
> time – almost a whole year! – between 5.6.2 and 5.6.3).
>
> I would rather see LTS canceled and more effort put into the current
> releases, if having both is a problem.

Note that you can build newer QtWebEngine releases against LTS Qt

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

-- 
Regards,
Konstantin

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Florian Bruhin
On Mon, Jan 29, 2018 at 02:32:58PM +0100, Kevin Kofler wrote:
> Simon Hausmann wrote:
> > In the light of that, I think it would be better to keep the LTS branches
> > open longer and stop doing patch releases for minor releases that are not
> > LTS.
> 
> -1 from a distro packager perspective. LTS just does not fit together with 
> fast-moving distributions, and we really need those bugfix releases for the 
> branches we ship.
> 
> Especially QtWebEngine requires those bugfix releases for security fixes, 
> and tracking LTS is not that great there because the base Chromium gets old 
> pretty quickly, and websites start complaining (e.g., Google already 
> complains about 5.9 being an outdated Chromium) or even stop working 
> altogether. The frequency of LTS releases has also so far been totally 
> insufficient to keep up with Chromium security fixes (see the huge amount of 
> time – almost a whole year! – between 5.6.2 and 5.6.3).
> 
> I would rather see LTS canceled and more effort put into the current 
> releases, if having both is a problem.

I can't agree more - while I'm not a distro packager, I'm a maintainer
of an opensource project[1] using QtWebEngine.

5.x.0 releases are often quite painful, as they're full of regressions
introduced because of new Chromium versions. I try to find report those
as soon as possible, but there are always issues ([2] for an example)
which only surface after a release.

Like Kevin said, of course security updates are also a big issue, and
only getting them all 6 months is definitely not good...

Florian

[1] https://www.qutebrowser.org/
[2] https://bugreports.qt.io/browse/QTBUG-65223

-- 
https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
 I love long mails!  | https://email.is-not-s.ms/


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Paolo Angelelli
On Mon, 29 Jan 2018 10:31:14 +0100
Giuseppe D'Angelo  wrote:

> On 29/01/18 07:59, Jani Heikkinen wrote:
> > We have currently really many branches open:
> > - 5.6
> > - 5.9
> > - 5.10
> > - 5.10.1
> > - 5.11
> > - dev
> > 
> > In my opinion this is too much to handle effectively, especially because 
> > there is many branches in stable mode (see 
> > http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' 
> > is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we 
> > need to change that to be able to work efficiently & get releases out.   
> 
> Could you please elaborate, what's the problem at the moment when you
> say that it's "too much" to handle? Is it a matter that branches have
> become different enough that merges don't apply any longer? Is it a
> matter of bandwidth for the releasing team having to produce releases
> from several branches?
> 
> > 
> > So I am proposing following changes starting from 1st Feb 2018:
> > 
> > - '5.6' will move in 'very strict' mode   
> 
> Which by the way is already the case, in practice. E.g. there have been
> ~20-30 patches landing in qtbase/5.6, with over half being fixes for
> flaky autotests.
> 
> > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
> > cherry picks from stable  
> 
> This was also proposed a few days ago (to change in 'strict' mode after
> 5.11 branching is completed). I have mixed feelings about that, in the
> sense that in 6 months from now noone will be doing the cherry-picks
> because of the extra work, thus leaving bugs in 5.9 in the name of
> stability, but somehow breaks the LTS promise.

+1
This will also introduce extra work in patching 5.9 (every change that has to 
go to 5.9 has to be pushed twice, due to no more forward merges)

> 
> > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 
> > 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 
> > active too long)  
> 
> I don't agree, 5.10 releases should be done on a regular basis until
> 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...)

+1 here too
Closing 5.10 before 5.11 isn't even released, and actually after just 2 months 
of releasing, also doesn't seem good marketing material for the project..

> 
> My 2 cents,

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Kevin Kofler
Giuseppe D'Angelo wrote:
> I don't agree, 5.10 releases should be done on a regular basis until
> 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...)

+1, I also agree with you and therefore disagree with the original proposal.

Especially security warrants always having one current release branch 
active. There is one Qt component (QtWebEngine) for which it is essentially 
GUARANTEED that there will be security concerns to address. In addition, 
security issues can hit any Qt component at any time. Those MUST be 
addressed in a timely manner for Qt to be usable.

While offering security fixes as patches attached to security advisories can 
work for some components, this is not always workable. In particular, 
QtWebEngine just cannot be handled that way.

And of course, there can also be other bugs that users will want fixed 
sooner rather than later.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Kevin Kofler
Simon Hausmann wrote:
> In the light of that, I think it would be better to keep the LTS branches
> open longer and stop doing patch releases for minor releases that are not
> LTS.

-1 from a distro packager perspective. LTS just does not fit together with 
fast-moving distributions, and we really need those bugfix releases for the 
branches we ship.

Especially QtWebEngine requires those bugfix releases for security fixes, 
and tracking LTS is not that great there because the base Chromium gets old 
pretty quickly, and websites start complaining (e.g., Google already 
complains about 5.9 being an outdated Chromium) or even stop working 
altogether. The frequency of LTS releases has also so far been totally 
insufficient to keep up with Chromium security fixes (see the huge amount of 
time – almost a whole year! – between 5.6.2 and 5.6.3).

I would rather see LTS canceled and more effort put into the current 
releases, if having both is a problem.

Kevin Kofler

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Konstantin Tokarev


29.01.2018, 15:30, "Simon Hausmann" <simon.hausm...@qt.io>:
> Right, so one patch release per non-LTS minor release to fix bloopers :)

If there are bugs featured in "Known Issues" which can be fixed in reasonable 
time
they could be merged directly to 5.x.1 branch after 1-week deadline as an 
exception.

>
> Simon
> 
> From: Konstantin Tokarev <annu...@yandex.ru>
> Sent: Monday, January 29, 2018 1:27:49 PM
> To: Simon Hausmann; Jani Heikkinen; development@qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
>
> 29.01.2018, 11:16, "Simon Hausmann" <simon.hausm...@qt.io>:
>> Hi,
>>
>> I feel that we are generally guiding our users towards the LTS releases. The 
>> minor releases appear to address in particular users who need a particular 
>> feature before it hits the next LTS release.
>>
>> In the light of that, I think it would be better to keep the LTS branches 
>> open longer and stop doing patch releases for minor releases that are not 
>> LTS.
>
> When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x 
> branch which missed the release because of timing issues.
>
> I propose following workflow:
>
> 1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there
> 2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with 
> usual one-week buffer time
> 3) after that, 5.x is closed down
>
>>
>> Simon
>> 
>> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> 
>> on behalf of Jani Heikkinen <jani.heikki...@qt.io>
>> Sent: Monday, January 29, 2018 7:59:06 AM
>> To: development@qt-project.org
>> Subject: [Development] Qt branches & proposal how to continue with those
>>
>> Hi,
>>
>> We have currently really many branches open:
>> - 5.6
>> - 5.9
>> - 5.10
>> - 5.10.1
>> - 5.11
>> - dev
>>
>> In my opinion this is too much to handle effectively, especially because 
>> there is many branches in stable mode (see 
>> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' 
>> is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we 
>> need to change that to be able to work efficiently & get releases out.
>>
>> So I am proposing following changes starting from 1st Feb 2018:
>>
>> - '5.6' will move in 'very strict' mode
>> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
>> cherry picks from stable
>> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
>> series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
>> long)
>> - '5.11' will be to one and only stable branch
>>
>> br,
>>
>> Jani
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>> ,
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Simon Hausmann

Right, so one patch release per non-LTS minor release to fix bloopers :)


Simon


From: Konstantin Tokarev <annu...@yandex.ru>
Sent: Monday, January 29, 2018 1:27:49 PM
To: Simon Hausmann; Jani Heikkinen; development@qt-project.org
Subject: Re: [Development] Qt branches & proposal how to continue with those



29.01.2018, 11:16, "Simon Hausmann" <simon.hausm...@qt.io>:
> Hi,
>
> I feel that we are generally guiding our users towards the LTS releases. The 
> minor releases appear to address in particular users who need a particular 
> feature before it hits the next LTS release.
>
> In the light of that, I think it would be better to keep the LTS branches 
> open longer and stop doing patch releases for minor releases that are not LTS.

When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x 
branch which missed the release because of timing issues.

I propose following workflow:

1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there
2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with 
usual one-week buffer time
3) after that, 5.x is closed down

>
> Simon
> 
> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> 
> on behalf of Jani Heikkinen <jani.heikki...@qt.io>
> Sent: Monday, January 29, 2018 7:59:06 AM
> To: development@qt-project.org
> Subject: [Development] Qt branches & proposal how to continue with those
>
> Hi,
>
> We have currently really many branches open:
> - 5.6
> - 5.9
> - 5.10
> - 5.10.1
> - 5.11
> - dev
>
> In my opinion this is too much to handle effectively, especially because 
> there is many branches in stable mode (see 
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is 
> in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need 
> to change that to be able to work efficiently & get releases out.
>
> So I am proposing following changes starting from 1st Feb 2018:
>
> - '5.6' will move in 'very strict' mode
> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
> cherry picks from stable
> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
> series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
> long)
> - '5.11' will be to one and only stable branch
>
> br,
>
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Konstantin Tokarev


29.01.2018, 11:16, "Simon Hausmann" :
> Hi,
>
> I feel that we are generally guiding our users towards the LTS releases. The 
> minor releases appear to address in particular users who need a particular 
> feature before it hits the next LTS release.
>
> In the light of that, I think it would be better to keep the LTS branches 
> open longer and stop doing patch releases for minor releases that are not LTS.

When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x 
branch which missed the release because of timing issues.

I propose following workflow:

1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there
2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with 
usual one-week buffer time
3) after that, 5.x is closed down

>
> Simon
> 
> From: Development  
> on behalf of Jani Heikkinen 
> Sent: Monday, January 29, 2018 7:59:06 AM
> To: development@qt-project.org
> Subject: [Development] Qt branches & proposal how to continue with those
>
> Hi,
>
> We have currently really many branches open:
> - 5.6
> - 5.9
> - 5.10
> - 5.10.1
> - 5.11
> - dev
>
> In my opinion this is too much to handle effectively, especially because 
> there is many branches in stable mode (see 
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is 
> in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need 
> to change that to be able to work efficiently & get releases out.
>
> So I am proposing following changes starting from 1st Feb 2018:
>
> - '5.6' will move in 'very strict' mode
> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
> cherry picks from stable
> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
> series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
> long)
> - '5.11' will be to one and only stable branch
>
> br,
>
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Bogdan Vatra
Hi,

  As long as we don't have enough time fix all the problems in a non LTS 
release, I think releasing at least one patch version is not that bad ...

Yours,
BogDan.

În ziua de luni, 29 ianuarie 2018, la 10:15:51 EET, Simon Hausmann a scris:
> Hi,
> 
> 
> I feel that we are generally guiding our users towards the LTS releases. The
> minor releases appear to address in particular users who need a particular
> feature before it hits the next LTS release.
> 
> 
> In the light of that, I think it would be better to keep the LTS branches
> open longer and stop doing patch releases for minor releases that are not
> LTS.
> 
> 
> 
> Simon
> 
> 
> From: Development 
> on behalf of Jani Heikkinen  Sent: Monday, January
> 29, 2018 7:59:06 AM
> To: development@qt-project.org
> Subject: [Development] Qt branches & proposal how to continue with those
> 
> Hi,
> 
> We have currently really many branches open:
> - 5.6
> - 5.9
> - 5.10
> - 5.10.1
> - 5.11
> - dev
> 
> In my opinion this is too much to handle effectively, especially because
> there is many branches in stable mode (see
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6'
> is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we
> need to change that to be able to work efficiently & get releases out.
> 
> So I am proposing following changes starting from 1st Feb 2018:
> 
> - '5.6' will move in 'very strict' mode
> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just
> cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the
> final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we
> shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only
> stable branch
> 
> br,
> 
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Adam Treat
“stop doing patch releases for minor releases that are not LTS.”

+1

_
From: Simon Hausmann <simon.hausm...@qt.io>
Sent: Monday, January 29, 2018 3:16 AM
Subject: Re: [Development] Qt branches & proposal how to continue with those
To: Jani Heikkinen <jani.heikki...@qt.io>, <development@qt-project.org>



Hi,


I feel that we are generally guiding our users towards the LTS releases. The 
minor releases appear to address in particular users who need a particular 
feature before it hits the next LTS release.


In the light of that, I think it would be better to keep the LTS branches open 
longer and stop doing patch releases for minor releases that are not LTS.



Simon


From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> on 
behalf of Jani Heikkinen <jani.heikki...@qt.io>
Sent: Monday, January 29, 2018 7:59:06 AM
To: development@qt-project.org
Subject: [Development] Qt branches & proposal how to continue with those

Hi,

We have currently really many branches open:
- 5.6
- 5.9
- 5.10
- 5.10.1
- 5.11
- dev

In my opinion this is too much to handle effectively, especially because there 
is many branches in stable mode 
(seehttp://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' 
is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need 
to change that to be able to work efficiently & get releases out.

So I am proposing following changes starting from 1st Feb 2018:

- '5.6' will move in 'very strict' mode
- '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
cherry picks from stable
- '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
long)
- '5.11' will be to one and only stable branch

br,

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


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Jani Heikkinen
> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Giuseppe D'Angelo
> Sent: maanantai 29. tammikuuta 2018 11.31
> To: development@qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
> 
> On 29/01/18 07:59, Jani Heikkinen wrote:
> > We have currently really many branches open:
> > - 5.6
> > - 5.9
> > - 5.10
> > - 5.10.1
> > - 5.11
> > - dev
> >
> > In my opinion this is too much to handle effectively, especially because 
> > there is
> many branches in stable mode (see
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is 
> in
> 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need to 
> change
> that to be able to work efficiently & get releases out.
> 
> Could you please elaborate, what's the problem at the moment when you say
> that it's "too much" to handle? Is it a matter that branches have become
> different enough that merges don't apply any longer? Is it a matter of 
> bandwidth
> for the releasing team having to produce releases from several branches?

The problem is resource usage side at the moment. I think merges are still 
applying quite well but it is really big effort needed to do merges from 
('5.9.x')->'5.9' ->(5.10.x)->'5.10'->'5.11'->'dev'. This is manpower, hw 
capasity and timing issue: It takes really long time to get a fix in every 
branch where it is needed and it also consumes lots of hw capasity to run CI on 
all these branches + run qt5.git integrations. And of course it is really hard 
for release team to get that much releases out (also HW usage point of view: 
RTA uses quite much resources while testing all these releases and snapshots). 

Moving '5.9' to strict mode helps there with merges and removing one release 
would help with all these issues, that's why I did this proposal.

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Giuseppe D'Angelo
On 29/01/18 07:59, Jani Heikkinen wrote:
> We have currently really many branches open:
> - 5.6
> - 5.9
> - 5.10
> - 5.10.1
> - 5.11
> - dev
> 
> In my opinion this is too much to handle effectively, especially because 
> there is many branches in stable mode (see 
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is 
> in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need 
> to change that to be able to work efficiently & get releases out. 

Could you please elaborate, what's the problem at the moment when you
say that it's "too much" to handle? Is it a matter that branches have
become different enough that merges don't apply any longer? Is it a
matter of bandwidth for the releasing team having to produce releases
from several branches?

> 
> So I am proposing following changes starting from 1st Feb 2018:
> 
> - '5.6' will move in 'very strict' mode 

Which by the way is already the case, in practice. E.g. there have been
~20-30 patches landing in qtbase/5.6, with over half being fixes for
flaky autotests.

> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
> cherry picks from stable

This was also proposed a few days ago (to change in 'strict' mode after
5.11 branching is completed). I have mixed feelings about that, in the
sense that in 6 months from now noone will be doing the cherry-picks
because of the extra work, thus leaving bugs in 5.9 in the name of
stability, but somehow breaks the LTS promise.

> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
> series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
> long)

I don't agree, 5.10 releases should be done on a regular basis until
5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...)

My 2 cents,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Lars Knoll
> On 29 Jan 2018, at 10:00, Uwe Rathmann  wrote:
> 
> On Mon, 29 Jan 2018 06:59:06 +, Jani Heikkinen wrote:
> 
>> - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict'
>> mode.
> 
> This type of discussion has to be lead, before making a LTS promise !

Of course. We had that discussion, see QUIP 5. 

According to what's defined there, 5.6 should move into 'very strict' mode for 
the third year, so that is pretty much from now onwards.
5.9 should move into strict mode with cherry-picking, also in line with QUIP 5.

So I agree with these two changes, they are IMO fully in line with what we have 
said and promised.

I think this only leaves a question around the proposal for 5.10. We've usually 
left that branch open until the next minor release is out.

Cheers,
Lars

> 
> Trying to change this later - without having any argument beside, that 
> maintaining stable branches is cumbersome - makes your LTS promises 
> nothing but unreliable.
> 
> But IMHO you are also asking the wrong audience. Qt development is the 
> right group, when discussing if a release should be a LTS one. But if you 
> want to change the cycle of an existing LTS version you should ask those 
> to whom you made the promise: the users.
> 
> Speaking for myself: I'm only interested in LTS versions and I could 
> easily live without releases that never go beyond 5.x.1 ( like f.e 5.10 ).
> 
> Uwe
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Uwe Rathmann
On Mon, 29 Jan 2018 06:59:06 +, Jani Heikkinen wrote:

> - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict'
> mode.

This type of discussion has to be lead, before making a LTS promise !

Trying to change this later - without having any argument beside, that 
maintaining stable branches is cumbersome - makes your LTS promises 
nothing but unreliable.

But IMHO you are also asking the wrong audience. Qt development is the 
right group, when discussing if a release should be a LTS one. But if you 
want to change the cycle of an existing LTS version you should ask those 
to whom you made the promise: the users.

Speaking for myself: I'm only interested in LTS versions and I could 
easily live without releases that never go beyond 5.x.1 ( like f.e 5.10 ).

Uwe


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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Simon Hausmann
Hi,


I feel that we are generally guiding our users towards the LTS releases. The 
minor releases appear to address in particular users who need a particular 
feature before it hits the next LTS release.


In the light of that, I think it would be better to keep the LTS branches open 
longer and stop doing patch releases for minor releases that are not LTS.



Simon


From: Development  on 
behalf of Jani Heikkinen 
Sent: Monday, January 29, 2018 7:59:06 AM
To: development@qt-project.org
Subject: [Development] Qt branches & proposal how to continue with those

Hi,

We have currently really many branches open:
- 5.6
- 5.9
- 5.10
- 5.10.1
- 5.11
- dev

In my opinion this is too much to handle effectively, especially because there 
is many branches in stable mode (see 
http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is 
in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need to 
change that to be able to work efficiently & get releases out.

So I am proposing following changes starting from 1st Feb 2018:

- '5.6' will move in 'very strict' mode
- '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
cherry picks from stable
- '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
long)
- '5.11' will be to one and only stable branch

br,

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Ville Voutilainen
On 29 January 2018 at 10:06, Jani Heikkinen  wrote:
>> On 29 January 2018 at 08:59, Jani Heikkinen  wrote:
>> > - '5.6' will move in 'very strict' mode
>> > - '5.9' will move in 'strict' mode. So no direct submissions anymore,
>> > just cherry picks from stable
>> > - '5.10' will be closed and Qt 5.10.1 will be the final release from
>> > Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt
>> > 5.10 active too long)
>> > - '5.11' will be to one and only stable branch
>>
>>
>> The problem here is that there are bugfixes that need to go into 5.9 but 
>> cannot
>> go into 5.11, for a variety of reasons. We need to keep 5.9 open for direct
>> submissions.
>
> Hmm, I think putting '5.9' in cherry pick mode with this schedule is agreed 
> way of working, see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst
> And I don't see big issue there; amount of 5.9 specific fixes should be 
> really minimal and if one really needed we can get that in without putting it 
> first in stable: Cherry pick "mode" is more "way of working" & checks are 
> included in sanity bot. And it can be overwritten if really needed.


Yeah, and I was actually thinking more along the lines of boot2qt,
where some things have completely different implementations
between 5.9 and 5.11, and changes just don't merge. So alrighty then,
consider my concern withdrawn.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt branches & proposal how to continue with those

2018-01-29 Thread Jani Heikkinen
> -Original Message-
> From: Ville Voutilainen [mailto:ville.voutilai...@gmail.com]
> Sent: maanantai 29. tammikuuta 2018 9.50
> To: Jani Heikkinen <jani.heikki...@qt.io>
> Cc: development@qt-project.org
> Subject: Re: [Development] Qt branches & proposal how to continue with those
> 
> On 29 January 2018 at 08:59, Jani Heikkinen <jani.heikki...@qt.io> wrote:
> > - '5.6' will move in 'very strict' mode
> > - '5.9' will move in 'strict' mode. So no direct submissions anymore,
> > just cherry picks from stable
> > - '5.10' will be closed and Qt 5.10.1 will be the final release from
> > Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt
> > 5.10 active too long)
> > - '5.11' will be to one and only stable branch
> 
> 
> The problem here is that there are bugfixes that need to go into 5.9 but 
> cannot
> go into 5.11, for a variety of reasons. We need to keep 5.9 open for direct
> submissions.

Hmm, I think putting '5.9' in cherry pick mode with this schedule is agreed way 
of working, see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst 
And I don't see big issue there; amount of 5.9 specific fixes should be really 
minimal and if one really needed we can get that in without putting it first in 
stable: Cherry pick "mode" is more "way of working" & checks are included in 
sanity bot. And it can be overwritten if really needed.

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


Re: [Development] Qt branches & proposal how to continue with those

2018-01-28 Thread Ville Voutilainen
On 29 January 2018 at 08:59, Jani Heikkinen  wrote:
> - '5.6' will move in 'very strict' mode
> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
> cherry picks from stable
> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
> series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
> long)
> - '5.11' will be to one and only stable branch


The problem here is that there are bugfixes that need to go into 5.9
but cannot go into 5.11, for a variety of reasons. We need to keep 5.9
open for direct submissions.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development