Re: [Development] Qt branches & proposal how to continue with those
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
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
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
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
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
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 they
Re: [Development] Qt branches & proposal how to continue with those
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
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
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
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
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
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
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
> 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
> 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
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
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
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
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
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
> 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
> 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
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
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
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 on behalf of Lars Knoll 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 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 ___ 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
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
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
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
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 alway
Re: [Development] Qt branches & proposal how to continue with those
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
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
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
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
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
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
-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 ; 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
> -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 ; 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
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
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
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
> -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
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
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
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
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
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
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
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
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
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
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
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
29.01.2018, 15:30, "Simon Hausmann" : > 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 > 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" : >> 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 -- 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
Right, so one patch release per non-LTS minor release to fix bloopers :) Simon From: Konstantin Tokarev 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" : > 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
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
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
“stop doing patch releases for minor releases that are not LTS.” +1 _ From: Simon Hausmann Sent: Monday, January 29, 2018 3:16 AM Subject: Re: [Development] Qt branches & proposal how to continue with those To: Jani Heikkinen , 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 (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
> -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
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
> 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
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
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
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
> -Original Message- > From: Ville Voutilainen [mailto:ville.voutilai...@gmail.com] > Sent: maanantai 29. tammikuuta 2018 9.50 > To: Jani Heikkinen > 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 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
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
