From jani.heikkinen at theqtcompany.com Tue Feb 2 13:51:29 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 2 Feb 2016 12:51:29 +0000 Subject: [Releasing] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: , Message-ID: Hi, Final downmerge is now done and branching is complete. From now on '5.6' is for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in the release team will stage needed changes in '5.6.0' from now on. We will check approved changes automatically so no need for any special actions from you; just take care that your changes will be approved. And please remember: We will take in only really important changes so please don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt 5.6.0 then please use '5.6' instead. And as usual please send re-targeting request to Ossi if there is some change open in '5.6' and which must be in Qt 5.6.0 br, Jani ________________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 25. tammikuuta 2016 13:39 Vastaanottaja: development at qt-project.org Kopio: releasing at qt-project.org Aihe: HEADS UP: Qt 5.6.0 branching ongoing ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt From jani.heikkinen at theqtcompany.com Thu Feb 4 07:58:31 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 4 Feb 2016 06:58:31 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 2.2.2016 Message-ID: Meeting minutes from Qt Release Team meeting 2nd February 2016 Qt 5.6 status: - Branching complete, all changes targeted to Qt 5.6.0 must be done in '5.6.0' - Staging is restricted in '5.6.0', release team will take care of staging there * We will take in only really important changes, all others should be done in '5.6' instead - We are targeting to produce new snapshot for testing as soon as possible * At the moment issues with getting new changes in qt5.git, see https://codereview.qt-project.org/#/c/147715/ - Plan is to get RC out ~2 weeks * Will be hard, we need to: 1. Get new changes in qt5.git first & create new snapshot for testhing 2. Fix remaining RC blockers (existing ones & new from snapshot testing), see blockers here: https://bugreports.qt.io/browse/QTQAINFRA-945?filter=17225 3. Integrate fixes in qt5.git & create rc packages 4. Verify rc packages & release RC if all OK Qt 5.7 status: - Feature Freeze in effect now - Branching not started yet, issues with adding new modules in qt5.git - At this time it should be much easier to get alpha src packages: ci is producing those so when we get successfully qt5.git integration we should be able to get proper src package as well * Hoping we can release Alpha as planned, current target schedule here: http://wiki.qt.io/Qt-5.7-release Next meeting Tue 9th February 16:00 CET br, Jani irc log below: [17:01:13] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:23] jaheikki3: pong [17:01:25] jaheikki3: pong [17:01:43] jaheikki3: pong [17:02:10] pong [17:02:59] jaheikki3:Pong [17:03:14] time to start qt release team meeting [17:03:24] on agenda today: [17:03:31] qt5.6.0 status [17:03:38] qt 5.7 status [17:03:47] Any additional item to the agenda? [17:06:23] ok, lets start from Qt 5.6.0 status [17:07:12] -Branching now complete, all changes for Qt 5.6.0 must be done in '5.6.0' from now on [17:07:45] Staging is restricted in '5.6.0', release team will take care of staging there [17:08:24] Target is to take in only really important changes, all others should be done in '5.6' instead [17:09:03] We are trying to produce new snapshot from '5.6.0' as soon as possible [17:09:44] Unfortunately there is some issues now with webkit builds. Fix available & under integration [17:10:05] WebEngine? [17:10:21] webkit builds? [17:10:30] webengine will probably need a merge from 5.6 to fix a failing test [17:10:35] After that is in we can try new qt5.git integration round & if that succeed then we can start creating new snapshot [17:10:41] but should be coming [17:11:32] fkleint: Actually it is webkit ;) it was agreed to deliver proper src package for it with 5.6 as well and it is now in the ci as well [17:11:56] Uargs, ok [17:13:18] See https://codereview.qt-project.org/#/c/147487/ [17:13:38] I'm going to play devil's advocate - seeing binaries are *built* by the CI anyways, what's the point in not distributing them anymore, seeing that many people consider QtWebEngine not yet ready for their projects? [17:13:48] we agreed to build to be sure webkit builds [17:13:53] we don't need binaries [17:14:17] yeah [17:14:37] as for not shipping something we built, we want to really discourage its use [17:14:50] however ready the replacement may be, webkit use needs to stop [17:15:36] I can't disagree with that ;) [17:16:58] RC blocker list here: https://bugreports.qt.io/issues/?filter=17225 [17:17:24] Still some open but most of those has fix proposal already available [17:18:29] We are targeting to get RC out ~2 weeks but let's see how long it takes to get first snapshot & what is still found when we get the testing results [17:19:10] Any comments / Questions? [17:21:22] it's taking too long [17:21:50] thiago: that is true [17:22:42] We are trying to speed it up as much as possible but I bet that 2 weeks won't be enough :( [17:22:51] why? [17:24:22] carewolf: Getting snapshot out takes a while. Getting testing results & rest of fixes a while as well. Then new packages + smoke testing. two weeks is short time for all this [17:24:35] But of course we are trying to keep that [17:25:05] did we get the beta out faster than that? [17:25:36] And it will help a lot if we can keep amount of changes in '5.6.0' as small as possible [17:25:54] not that I mind taking the time, but I still think we should then figure that time into our planing to begin with, and maybe schedule multiple betas or alphas [17:27:02] carewolf: Yeah, that 2 weeks is based on schedule of earlier releases [17:27:31] yeah, I know. [17:28:25] at this time 5.7 will make thinks a bit more difficult because we are doing it at same time ;) But we will handle that... [17:29:07] By the way, I'd really appreciate a blogpost or so about how the release process works, if someone has the time to do that. Because as a (mostly) Qt user, it's hard to imagine *what* work is taking so long :) [17:30:25] The-Compiler: Good idea, I try to wrote something at some point ;) [17:30:50] I think this was all about 5.6.0 at this time. [17:31:00] Then Qt 5.7.0 status: [17:31:15] Feature Freeze is now in effect [17:32:05] Unfortunately we haven't been able to start branching yet, there is still some issues with getting new modules in qt5.git [17:32:24] Hoping we can start it soon [17:33:01] Target schedule for 5.7 can be found here: http://wiki.qt.io/Qt-5.7-release [17:34:15] At this time it should be much easier to get alpha src packages: ci is producing those so when we get successfully qt5.git integration we should be able to get proper src package as well [17:34:46] So I am hoping we could get Alpha out latest as planned hoping already a bit earlier [17:35:10] But first we need to get those new modules in qt5.git & start branching [17:35:32] Any comments / questions? [17:35:35] what's the issue with new modules? [17:36:14] should we schedule a second optional alpha in case the beta is delayed/ [17:37:35] we haven't even had the first yet [17:38:08] I just mean if we should make it a policy if the beta is delayed more than a certain amount of time [17:38:11] the problem we have with new releases is that we can never predict how long it will take for the next [17:38:23] yeah [17:38:28] if we knew the beta would take at least 3 weeks from a given date, we could say "we'll ship a second alpha" [17:38:32] we can't [17:38:34] thiago: There is compilation break in qtscxml. [17:39:17] in any case, the purpose of the alpha is feature review. Unless we add more features, which we shouldn't because we're frozen, there's never a need for a second alpha. [17:39:21] we need to get merge from 5.6.0 to dev to fix that. it is ongoing [17:39:35] thiago: I agree [17:39:59] -*- thiago makes a point to complain about thousands of lines of code arriving shortly before the feature freeze and not having the proper time to stabilise them [17:40:17] if it were any other source, we'd have said, "hold your horses, we'll have you in the next release, not this one" [17:41:08] then just adding those missing new modules (qtscxml, qtgamepad) in the qt5.git [17:42:13] thiago:qtscxml will be TP in 5.7.0 so late arrival doesn't matter so much. But I understand your point [17:42:36] thiago: I was just thinking about the 5.6 beta problems, which was due to not being able to fix all the 'must be fixed before beta' bugs. [17:42:41] jaheikki3: it's mattering now [17:42:45] that negates your argument [17:42:56] if it didn t matter, we'd be progressing and ignoring its compilation error [17:43:07] thiago: Yes, from release schedule point of view it matters. [17:43:46] We discussed about that with lars & ossi yesterday in #qt-labs & this is to way to proceed now [17:44:29] As I said hoping we get those fixed & in soon to be able to proceed [17:45:04] Any other comments / questions? [17:47:16] discussion in IRC is not binding [17:47:41] anyway, conclusion is that it's impacting the release, for a module whose source was added to the Qt Project within the last month [17:47:51] big code drops should not be accepted this late in the cycle [17:48:06] this is just to log a protest. I'm not asking we drop it. [17:48:52] thiago: I understand. And even agree [17:49:35] Ok, I think it was all this time. Let's have new meeting after a week at this same time, OK? [17:50:59] ok [17:52:54] Great. Let's end this meeting now & have new one tue 9th Feb 16:00 CET [17:53:09] Thanks for your participation. Bye! [17:53:16] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Thu Feb 4 09:15:28 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 4 Feb 2016 09:15:28 +0100 Subject: [Releasing] Deprecation - we are doing that wrong Message-ID: <2431276.mndH6jJ9gQ@42> Hi, From time to time we are deprecating/removing a module. Great it is normal that certain technologies fade out. We announce that the module is deprecated and removed, then people start complaining, it is also normal. Nobody want to upgrade software because it is costly. Then we get scared and we say, "ah don't worry it is deprecated, but we will keep it working for a while and we will still ship packages with it...". That in my opinion is not normal. There are a few problems with it: 1. It is simply a lie, nobody is looking into that modules, and they are constantly broken. Which fall-through to 2nd point 2. Nobody cares, nobody is fixing problems there and we know about breakages only when we want to update qt5, which should happen as often as possible, but as deprecated modules are broken, we update qt5 without them. Which fall- through to the next point 3. It affects releases, as we need to ship packages with deprecated / removed modules, we need to update them in qt5. Now someone needs to be allocated to fix the problems. That is definitely too late in the process. 4. Why we deprecate something that is in use? Before deprecation we really need to make a decision. Is a module worth to be kept? Yes, do not deprecate/remove it. No? Then make a clear cut, do not ship it. Make the source available if someone want to invest in keeping it alive then un- deprecate or re-add it. The current situation is just creative book keeping. I'm writing this because of qtquick1 that blocks qt5 (https://codereview.qt-project.org/#/c/147715/) The issue was known for a while (https://codereview.qt-project.org/#/c/142991/, https://codereview.qt-project.org/#/c/126971/1). Just "one more" fix is needed to unlock it :> I see a few options: A. we ask someone to maintain a deprecated / removed module, but then I guess it would be better to change the status to Done. B. we can disable tests run on Qt5 for deprecated / removed modules. It would allow us to make the release, but essentially a module would stay locked down as it is now (currently you need to stage a few changes in one go to pass CI) C. we can disable tests completely for such modules. So we would assume that if they compile then they are good enough. You know what are the consequences of it. D. we can avoid shipping them completely Pick your poison. I would take D but that is because of I'm in the mood of cutting problems. C is probably fine too. B is just stinking compromise which would fail soon (you need to fix a module to get build fixes...). A is beyond my powers. Cheers, Jędrek From jani.heikkinen at theqtcompany.com Thu Feb 4 09:41:55 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 4 Feb 2016 08:41:55 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <2431276.mndH6jJ9gQ@42> References: <2431276.mndH6jJ9gQ@42> Message-ID: Hi! And thanks for really good mail! I also vote 'D'. It would make our live much easier and one who still wants to use those deprecated ones can get codes from git. br, Jani ________________________________________ Lähettäjä: Releasing käyttäjän puolestaJędrzej Nowacki Lähetetty: 4. helmikuuta 2016 10:15 Vastaanottaja: releasing at qt-project.org Aihe: [Releasing] Deprecation - we are doing that wrong Hi, From time to time we are deprecating/removing a module. Great it is normal that certain technologies fade out. We announce that the module is deprecated and removed, then people start complaining, it is also normal. Nobody want to upgrade software because it is costly. Then we get scared and we say, "ah don't worry it is deprecated, but we will keep it working for a while and we will still ship packages with it...". That in my opinion is not normal. There are a few problems with it: 1. It is simply a lie, nobody is looking into that modules, and they are constantly broken. Which fall-through to 2nd point 2. Nobody cares, nobody is fixing problems there and we know about breakages only when we want to update qt5, which should happen as often as possible, but as deprecated modules are broken, we update qt5 without them. Which fall- through to the next point 3. It affects releases, as we need to ship packages with deprecated / removed modules, we need to update them in qt5. Now someone needs to be allocated to fix the problems. That is definitely too late in the process. 4. Why we deprecate something that is in use? Before deprecation we really need to make a decision. Is a module worth to be kept? Yes, do not deprecate/remove it. No? Then make a clear cut, do not ship it. Make the source available if someone want to invest in keeping it alive then un- deprecate or re-add it. The current situation is just creative book keeping. I'm writing this because of qtquick1 that blocks qt5 (https://codereview.qt-project.org/#/c/147715/) The issue was known for a while (https://codereview.qt-project.org/#/c/142991/, https://codereview.qt-project.org/#/c/126971/1). Just "one more" fix is needed to unlock it :> I see a few options: A. we ask someone to maintain a deprecated / removed module, but then I guess it would be better to change the status to Done. B. we can disable tests run on Qt5 for deprecated / removed modules. It would allow us to make the release, but essentially a module would stay locked down as it is now (currently you need to stage a few changes in one go to pass CI) C. we can disable tests completely for such modules. So we would assume that if they compile then they are good enough. You know what are the consequences of it. D. we can avoid shipping them completely Pick your poison. I would take D but that is because of I'm in the mood of cutting problems. C is probably fine too. B is just stinking compromise which would fail soon (you need to fix a module to get build fixes...). A is beyond my powers. Cheers, Jędrek _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing From Shawn.Rutledge at theqtcompany.com Thu Feb 4 10:23:12 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Thu, 4 Feb 2016 09:23:12 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <2431276.mndH6jJ9gQ@42> References: <2431276.mndH6jJ9gQ@42> Message-ID: > On 4 Feb 2016, at 09:15, Jędrzej Nowacki wrote: > I see a few options: > A. we ask someone to maintain a deprecated / removed module, but then I guess > it would be better to change the status to Done. > B. we can disable tests run on Qt5 for deprecated / removed modules. It would > allow us to make the release, but essentially a module would stay locked down > as it is now (currently you need to stage a few changes in one go to pass CI) > C. we can disable tests completely for such modules. So we would assume that > if they compile then they are good enough. You know what are the consequences > of it. > D. we can avoid shipping them completely > > Pick your poison. I would take D but that is because of I'm in the mood of > cutting problems. C is probably fine too. B is just stinking compromise which > would fail soon (you need to fix a module to get build fixes...). A is beyond my > powers. Probably QtQuick 1 could be in category D by now - it hasn’t been maintained for a long time. Even before that it was on life support mainly because Creator needed it. Whereas Webkit and QtScript are still too popular, even though we’d like to get rid of them, right? QtQuick 2 has never had paint(QPainter*) methods on the Items, as in QQ1. The only reasons I know of are that maybe it would be considered misleading - people would think the paint method was used for rendering normally, whereas it’s really not; and so that we could keep the 2D renderer separate and charge money for it. But now the second reason has gone away, so if we make it easy to render a QtQuick 2 item tree the same way as in QQ1, then maybe people will not miss QQ1 anymore. Besides, I need those paint methods to be able to work on QtQuick printing support later on. About QtScript, we didn’t really finish replacing all its use cases with V4 yet, did we? At least a while back, people were complaining that they still can’t switch. From oswald.buddenhagen at theqtcompany.com Thu Feb 4 11:07:25 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 11:07:25 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <2431276.mndH6jJ9gQ@42> References: <2431276.mndH6jJ9gQ@42> Message-ID: <20160204100725.GD28951@troll08.it.local> On Thu, Feb 04, 2016 at 09:15:28AM +0100, Jędrzej Nowacki wrote: > C. we can disable tests completely for such modules. So we would > assume that if they compile then they are good enough. You know what > are the consequences of it. > that was the idea behind re-integrating them into the supermodule. From jedrzej.nowacki at theqtcompany.com Thu Feb 4 11:12:36 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 4 Feb 2016 11:12:36 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: References: <2431276.mndH6jJ9gQ@42> Message-ID: <5471288.le47lmK4xe@42> On Thursday 04 of February 2016 09:23:12 Rutledge Shawn wrote: > > On 4 Feb 2016, at 09:15, Jędrzej Nowacki > > wrote: I see a few options: > > A. we ask someone to maintain a deprecated / removed module, but then I > > guess it would be better to change the status to Done. > > B. we can disable tests run on Qt5 for deprecated / removed modules. It > > would allow us to make the release, but essentially a module would stay > > locked down as it is now (currently you need to stage a few changes in > > one go to pass CI) C. we can disable tests completely for such modules. > > So we would assume that if they compile then they are good enough. You > > know what are the consequences of it. > > D. we can avoid shipping them completely > > > > Pick your poison. I would take D but that is because of I'm in the mood of > > cutting problems. C is probably fine too. B is just stinking compromise > > which would fail soon (you need to fix a module to get build fixes...). A > > is beyond my powers. > > > Probably QtQuick 1 could be in category D by now - it hasn’t been maintained > for a long time. Even before that it was on life support mainly because > Creator needed it. Whereas Webkit and QtScript are still too popular, even > though we’d like to get rid of them, right? > QtQuick 2 has never had paint(QPainter*) methods on the Items, as in QQ1. > The only reasons I know of are that maybe it would be considered misleading > - people would think the paint method was used for rendering normally, > whereas it’s really not; and so that we could keep the 2D renderer separate > and charge money for it. But now the second reason has gone away, so if we > make it easy to render a QtQuick 2 item tree the same way as in QQ1, then > maybe people will not miss QQ1 anymore. > Besides, I need those paint methods to be able to work on QtQuick printing > support later on. > About QtScript, we didn’t really finish replacing all its use cases with V4 > yet, did we? At least a while back, people were complaining that they > still can’t switch. As I wrote before technologies are changing and therefore use cases are changing too. I do not believe that we as Qt project need to keep feature parity forever for everything (QtScript case). Anyway my mail was not about if we should deprecate these modules, but what kind of level of quarantines are we giving for them. We already decided that we do not want to invest into them, but it seems that it is just a wishful thinking. It seems that with the current setup we need to compile and test them, which is essentially what we are doing for Done modules. Cheers, Jędrek From robin+qt at viroteck.net Thu Feb 4 11:43:12 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Thu, 04 Feb 2016 11:43:12 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <2431276.mndH6jJ9gQ@42> References: <2431276.mndH6jJ9gQ@42> Message-ID: <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> Hi, Well written mail :) On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote: > From time to time we are deprecating/removing a module. Great it is normal > that certain technologies fade out. We announce that the module is > deprecated and removed, then people start complaining, it is also normal. Nobody > want to upgrade software because it is costly. Then we get scared and we say, "ah > don't worry it is deprecated, but we will keep it working for a while and > we will still ship packages with it...". That in my opinion is not normal. Agreed. If a spade is a spade, call it a spade. If nobody is working on it, and nobody will be working on it for valid reasons (whether technical like QtQuick1, or business in the case of QtWebkit where AIUI there simply aren't enough resources to dedicate the required effort to it), then it's deprecated, whether or not that's a popular announcement to make. Making that announcement takes courage, I'm sure, but it gives a much better impression to see deprecated technology that doesn't work rather than trying to use something (because it has no obvious warning label) and then wondering why it's massively broken. This, in turn, could give Qt a bad reputation to newcomers who don't understand this situation (and quite rightly so: it would be a bad one). > There are a few problems with it: , no disagreements here... > I see a few options: > A. we ask someone to maintain a deprecated / removed module, but then I > guess it would be better to change the status to Done. I don't think this is in practice an option, because in reality this is little more than life support. It basically means "we'll keep the lights on and fix compilation/test failures but nothing else" which in turn leads to the reputation hit that I already mentioned. > B. we can disable tests run on Qt5 for deprecated / removed modules. It > would allow us to make the release, but essentially a module would stay locked > down as it is now (currently you need to stage a few changes in one go to pass > CI) This sounds like 'c' with tests kept enabled for the module itself if I understand you right. And I don't like that option, it's very easy for tests to fail for reasons completely outside that module's control, and that shifts the headache from releasing onto making trivial compilation fixes (oh, I want to remove this semicolon that is now a warning with a new compiler, but I have to fix 60 other issues that broke in the meantime too.. yeah, maybe I just won't bother). > C. we can disable tests completely for such modules. So we would assume that > if they compile then they are good enough. You know what are the consequences > of it. Yes, but it also reflects reality: it's deprecated. There's nobody working on it. If nobody is working on it, there should be no real change going on in the module itself, and the deprecation has already indicated that we don't want to spend resources on testing and maintaining it. So this sounds better, since it allows trivial fixes without blocking either those fixes or releasing efforts. It does have the obvious downside of potential breakage. Perhaps staging should be restricted to either someone who wants to volunteer to undertake that for that module (or maintainers, collectively), who would be responsible for vetting changes to make sure they _are_ really just simple compilation fix-type things. > D. we can avoid shipping them completely Honestly, I'd prefer this. Deprecated (to me) means zero effort expended, but I guess there was already a decision taken to reverse this for reasons I'm too lazy to go find out right now. I guess a combination of C & D could also be an option: don't ship them, and disable testing to enable easy fixes from whoever wants to volunteer to go make them. -- Robin Burchell robin at viroteck.net From Lars.Knoll at theqtcompany.com Thu Feb 4 12:09:52 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 11:09:52 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> Message-ID: Hi, I also believe Option D (ie. We don’t ship them) is the best idea. It can’t be that modules that we said are unsupported block us from getting a release out. Here is how I think we should do things: We remove qtquick1 and qtwebkit from the set of modules we compile and test when doing qt5.git integrations. Like that these modules will not ever block us from getting a release out. We know that these modules are still in use in some places, and that Linux distributions and some of our customers would appreciate some tar ball that compiles and works against 5.6, so that they can update their stack. To accommodate for this, we can spend a bit of time to get the 5.6 branch of these modules passing in CI. That can be done completely independent of our packaging and release process, and doesn’t have to happen at the same time. Once we have a version that passes CI, we take the source tar ball created by CI, put that onto our ftp server under 5.6/unsupported/qtquick1.tgz (or similar). This means that our 5.6 release doesn’t anymore have _any_ dependencies towards these modules. We can do some work on them independently, and then at a later state release some source tarball for them. Cheers, Lars On 04/02/16 11:43, "Releasing on behalf of Robin Burchell" wrote: >Hi, > >Well written mail :) > >On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote: >> From time to time we are deprecating/removing a module. Great it is normal >> that certain technologies fade out. We announce that the module is >> deprecated and removed, then people start complaining, it is also normal. Nobody >> want to upgrade software because it is costly. Then we get scared and we say, "ah >> don't worry it is deprecated, but we will keep it working for a while and >> we will still ship packages with it...". That in my opinion is not normal. > >Agreed. If a spade is a spade, call it a spade. If nobody is working on >it, and nobody will be working on it for valid reasons (whether >technical like QtQuick1, or business in the case of QtWebkit where AIUI >there simply aren't enough resources to dedicate the required effort to >it), then it's deprecated, whether or not that's a popular announcement >to make. > >Making that announcement takes courage, I'm sure, but it gives a much >better impression to see deprecated technology that doesn't work rather >than trying to use something (because it has no obvious warning label) >and then wondering why it's massively broken. This, in turn, could give >Qt a bad reputation to newcomers who don't understand this situation >(and quite rightly so: it would be a bad one). > >> There are a few problems with it: > >, no disagreements here... > >> I see a few options: >> A. we ask someone to maintain a deprecated / removed module, but then I >> guess it would be better to change the status to Done. > >I don't think this is in practice an option, because in reality this is >little more than life support. It basically means "we'll keep the lights >on and fix compilation/test failures but nothing else" which in turn >leads to the reputation hit that I already mentioned. > >> B. we can disable tests run on Qt5 for deprecated / removed modules. It >> would allow us to make the release, but essentially a module would stay locked >> down as it is now (currently you need to stage a few changes in one go to pass >> CI) > >This sounds like 'c' with tests kept enabled for the module itself if I >understand you right. And I don't like that option, it's very easy for >tests to fail for reasons completely outside that module's control, and >that shifts the headache from releasing onto making trivial compilation >fixes (oh, I want to remove this semicolon that is now a warning with a >new compiler, but I have to fix 60 other issues that broke in the >meantime too.. yeah, maybe I just won't bother). > >> C. we can disable tests completely for such modules. So we would assume that >> if they compile then they are good enough. You know what are the consequences >> of it. > >Yes, but it also reflects reality: it's deprecated. There's nobody >working on it. If nobody is working on it, there should be no real >change going on in the module itself, and the deprecation has already >indicated that we don't want to spend resources on testing and >maintaining it. So this sounds better, since it allows trivial fixes >without blocking either those fixes or releasing efforts. > >It does have the obvious downside of potential breakage. Perhaps staging >should be restricted to either someone who wants to volunteer to >undertake that for that module (or maintainers, collectively), who would >be responsible for vetting changes to make sure they _are_ really just >simple compilation fix-type things. > >> D. we can avoid shipping them completely > >Honestly, I'd prefer this. Deprecated (to me) means zero effort >expended, but I guess there was already a decision taken to reverse this >for reasons I'm too lazy to go find out right now. I guess a combination >of C & D could also be an option: don't ship them, and disable testing >to enable easy fixes from whoever wants to volunteer to go make them. > >-- > Robin Burchell > robin at viroteck.net >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing From oswald.buddenhagen at theqtcompany.com Thu Feb 4 12:23:42 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 12:23:42 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> Message-ID: <20160204112342.GF28951@troll08.it.local> On Thu, Feb 04, 2016 at 11:09:52AM +0000, Knoll Lars wrote: > We know that these modules are still in use in some places, and that > Linux distributions and some of our customers would appreciate some > tar ball that compiles and works against 5.6, so that they can update > their stack. To accommodate for this, we can spend a bit of time to > get the 5.6 branch of these modules passing in CI. That can be done > completely independent of our packaging and release process, and > doesn’t have to happen at the same time. Once we have a version that > passes CI, we take the source tar ball created by CI, put that onto > our ftp server under 5.6/unsupported/qtquick1.tgz (or similar). > that makes no sense. building and maintaining this parallel not-quite-release infrastructure would be more effort than keeping it building and dragging it along the normal releases. that's how we arrived at the previous conclusion to "soften" the removal. i don't think we should spend effort on keeping the autotests passing. we can include them in the state builds, so willing parts of the community can monitor it, but that's a far as i would go beyond keeping it building. From Lars.Knoll at theqtcompany.com Thu Feb 4 12:31:56 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 11:31:56 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204112342.GF28951@troll08.it.local> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> Message-ID: <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" wrote: >On Thu, Feb 04, 2016 at 11:09:52AM +0000, Knoll Lars wrote: >> We know that these modules are still in use in some places, and that >> Linux distributions and some of our customers would appreciate some >> tar ball that compiles and works against 5.6, so that they can update >> their stack. To accommodate for this, we can spend a bit of time to >> get the 5.6 branch of these modules passing in CI. That can be done >> completely independent of our packaging and release process, and >> doesn’t have to happen at the same time. Once we have a version that >> passes CI, we take the source tar ball created by CI, put that onto >> our ftp server under 5.6/unsupported/qtquick1.tgz (or similar). >> >that makes no sense. building and maintaining this parallel >not-quite-release infrastructure would be more effort than keeping it >building and dragging it along the normal releases. that's how we >arrived at the previous conclusion to "soften" the removal. I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out. And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical. Cheers, Lars > >i don't think we should spend effort on keeping the autotests passing. >we can include them in the state builds, so willing parts of the >community can monitor it, but that's a far as i would go beyond keeping >it building. >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing From oswald.buddenhagen at theqtcompany.com Thu Feb 4 12:50:05 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 12:50:05 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> Message-ID: <20160204115005.GA21907@troll08.it.local> On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: > On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" wrote: > >that makes no sense. building and maintaining this parallel > >not-quite-release infrastructure would be more effort than keeping it > >building and dragging it along the normal releases. that's how we > >arrived at the previous conclusion to "soften" the removal. > > I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out. > > And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical. > the effort to get it working now is just disabling the autotests for these modules during integration runs. this can be hacked into the CI within a very short time (the needed information is in exactly the patches that currently fail to integrate). this cannot be possibly more effort than would be required to do parallel releases, however minimal we try to make them. and it has a much higher pay-off beyond the next few days. From Lars.Knoll at theqtcompany.com Thu Feb 4 12:57:13 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 11:57:13 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204115005.GA21907@troll08.it.local> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> Message-ID: <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> On 04/02/16 12:50, "Releasing on behalf of Oswald Buddenhagen" wrote: >On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >that makes no sense. building and maintaining this parallel >> >not-quite-release infrastructure would be more effort than keeping it >> >building and dragging it along the normal releases. that's how we >> >arrived at the previous conclusion to "soften" the removal. >> >> I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out. >> >> And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical. >> >the effort to get it working now is just disabling the autotests for >these modules during integration runs. this can be hacked into the CI >within a very short time (the needed information is in exactly the >patches that currently fail to integrate). > >this cannot be possibly more effort than would be required to do >parallel releases, however minimal we try to make them. and it has a >much higher pay-off beyond the next few days. Disabling testing these modules has to be hacked into the CI. Disabling them from being compiled is a simple change in qt5.git, so it’s even easier. And seeing that we’re having these problems again and again, I believe that we have a higher pay-off in the long term by removing them. They aren’t part of the release, they are not really maintained, so I don’t want us to have to deal with these modules to get our release out. Like that we decouple the problems and can work on getting some source packages for these unsupported modules with a different time schedule. Cheers, Lars From tuukka.turunen at theqtcompany.com Thu Feb 4 13:04:09 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 4 Feb 2016 12:04:09 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> Message-ID: Hi, One additional thing to note is the phasing from Done -> Deprecated -> Removed. It would be valuable if a functionality is marked Deprecated in at least one release of Qt before it is Removed. In some extreme case this may not work, but for most modules it should be well feasible and something we have regularly done. The more profound question to me is why put effort into having Removed modules working with a new release. Yours, Tuukka > -----Original Message----- > From: Releasing [mailto:releasing-bounces at qt-project.org] On Behalf Of > Knoll Lars > Sent: torstaina 4. helmikuuta 2016 13.57 > To: Buddenhagen Oswald ; > releasing at qt-project.org > Subject: Re: [Releasing] Deprecation - we are doing that wrong > > On 04/02/16 12:50, "Releasing on behalf of Oswald Buddenhagen" > oswald.buddenhagen at theqtcompany.com> wrote: > > > > >On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: > >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" > oswald.buddenhagen at theqtcompany.com> wrote: > >> >that makes no sense. building and maintaining this parallel > >> >not-quite-release infrastructure would be more effort than keeping > >> >it building and dragging it along the normal releases. that's how we > >> >arrived at the previous conclusion to "soften" the removal. > >> > >> I don’t agree. I want to get rid of things that make it harder for us to > release Qt. That’s what is IMO most important, given how we have fight to > get releases out. > >> > >> And I don’t think there’s a lot of effort involved, as the CI can test these > modules independently. Actually we might save ourselves at some work, as > we separate the problems. At least we will have a lot less pressure with that > work, as it doesn’t block anything critical. > >> > >the effort to get it working now is just disabling the autotests for > >these modules during integration runs. this can be hacked into the CI > >within a very short time (the needed information is in exactly the > >patches that currently fail to integrate). > > > >this cannot be possibly more effort than would be required to do > >parallel releases, however minimal we try to make them. and it has a > >much higher pay-off beyond the next few days. > > Disabling testing these modules has to be hacked into the CI. Disabling them > from being compiled is a simple change in qt5.git, so it’s even easier. > > And seeing that we’re having these problems again and again, I believe that > we have a higher pay-off in the long term by removing them. They aren’t > part of the release, they are not really maintained, so I don’t want us to have > to deal with these modules to get our release out. > > Like that we decouple the problems and can work on getting some source > packages for these unsupported modules with a different time schedule. > > Cheers, > Lars > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From Lars.Knoll at theqtcompany.com Thu Feb 4 13:08:37 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 12:08:37 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> Message-ID: I am only talking about Removed modules. While it’s good if we can provide some unsupported source packages for these to our users and the linux distributions, having these interfere in any way with getting our release out is simply something we can’t afford. Cheers, Lars On 04/02/16 13:04, "Turunen Tuukka" wrote: > >Hi, > >One additional thing to note is the phasing from Done -> Deprecated -> Removed. > >It would be valuable if a functionality is marked Deprecated in at least one release of Qt before it is Removed. In some extreme case this may not work, but for most modules it should be well feasible and something we have regularly done. > >The more profound question to me is why put effort into having Removed modules working with a new release. > >Yours, > > Tuukka > >> -----Original Message----- >> From: Releasing [mailto:releasing-bounces at qt-project.org] On Behalf Of >> Knoll Lars >> Sent: torstaina 4. helmikuuta 2016 13.57 >> To: Buddenhagen Oswald ; >> releasing at qt-project.org >> Subject: Re: [Releasing] Deprecation - we are doing that wrong >> >> On 04/02/16 12:50, "Releasing on behalf of Oswald Buddenhagen" >> > oswald.buddenhagen at theqtcompany.com> wrote: >> >> >> >> >On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: >> >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" >> > oswald.buddenhagen at theqtcompany.com> wrote: >> >> >that makes no sense. building and maintaining this parallel >> >> >not-quite-release infrastructure would be more effort than keeping >> >> >it building and dragging it along the normal releases. that's how we >> >> >arrived at the previous conclusion to "soften" the removal. >> >> >> >> I don’t agree. I want to get rid of things that make it harder for us to >> release Qt. That’s what is IMO most important, given how we have fight to >> get releases out. >> >> >> >> And I don’t think there’s a lot of effort involved, as the CI can test these >> modules independently. Actually we might save ourselves at some work, as >> we separate the problems. At least we will have a lot less pressure with that >> work, as it doesn’t block anything critical. >> >> >> >the effort to get it working now is just disabling the autotests for >> >these modules during integration runs. this can be hacked into the CI >> >within a very short time (the needed information is in exactly the >> >patches that currently fail to integrate). >> > >> >this cannot be possibly more effort than would be required to do >> >parallel releases, however minimal we try to make them. and it has a >> >much higher pay-off beyond the next few days. >> >> Disabling testing these modules has to be hacked into the CI. Disabling them >> from being compiled is a simple change in qt5.git, so it’s even easier. >> >> And seeing that we’re having these problems again and again, I believe that >> we have a higher pay-off in the long term by removing them. They aren’t >> part of the release, they are not really maintained, so I don’t want us to have >> to deal with these modules to get our release out. >> >> Like that we decouple the problems and can work on getting some source >> packages for these unsupported modules with a different time schedule. >> >> Cheers, >> Lars >> >> _______________________________________________ >> Releasing mailing list >> Releasing at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/releasing From oswald.buddenhagen at theqtcompany.com Thu Feb 4 13:25:10 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 13:25:10 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> Message-ID: <20160204122510.GD21907@troll08.it.local> On Thu, Feb 04, 2016 at 12:57:13PM +0100, Knoll Lars wrote: > On 04/02/16 12:50, "Releasing on behalf of Oswald Buddenhagen" wrote: > >On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: > >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" wrote: > >> >that makes no sense. building and maintaining this parallel > >> >not-quite-release infrastructure would be more effort than keeping it > >> >building and dragging it along the normal releases. that's how we > >> >arrived at the previous conclusion to "soften" the removal. > >> > >> I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out. > >> > >> And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical. > >> > >the effort to get it working now is just disabling the autotests for > >these modules during integration runs. this can be hacked into the CI > >within a very short time (the needed information is in exactly the > >patches that currently fail to integrate). > > > >this cannot be possibly more effort than would be required to do > >parallel releases, however minimal we try to make them. and it has a > >much higher pay-off beyond the next few days. > > Disabling testing these modules has to be hacked into the CI. Disabling them from being compiled is a simple change in qt5.git, so it’s even easier. > yes, right in this second. that's not what i call a strategy. > And seeing that we’re having these problems again and again, I believe > that we have a higher pay-off in the long term by removing them. They > aren’t part of the release, they are not really maintained, so I don’t > want us to have to deal with these modules to get our release out. > we already *know* that we have to do at least minimal maintenance of them. users have *told* us so. and for that matter, it's some very creative interpretation of the backwards compatibility promise to say that removing entire modules doesn't violate it. we tried to weasel out of that by saying they could continue to use the old versions with new qt releases. we (predictably) failed at that, so we have to deliver an alternative. so any reasonable calculation of pay-off assumes these modules' presence until qt6. > Like that we decouple the problems and can work on getting some source > packages for these unsupported modules with a different time schedule. > why do you think that we'll *ever* have more time for that than right now? especially given that it will be *more* total effort if we take it out of the general process? and that doesn't even consider the user perspective on these pseudo releases ... From Lars.Knoll at theqtcompany.com Thu Feb 4 13:30:46 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 12:30:46 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204122510.GD21907@troll08.it.local> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> Message-ID: On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" wrote: >On Thu, Feb 04, 2016 at 12:57:13PM +0100, Knoll Lars wrote: >> On 04/02/16 12:50, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >On Thu, Feb 04, 2016 at 12:31:56PM +0100, Knoll Lars wrote: >> >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >> >that makes no sense. building and maintaining this parallel >> >> >not-quite-release infrastructure would be more effort than keeping it >> >> >building and dragging it along the normal releases. that's how we >> >> >arrived at the previous conclusion to "soften" the removal. >> >> >> >> I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out. >> >> >> >> And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical. >> >> >> >the effort to get it working now is just disabling the autotests for >> >these modules during integration runs. this can be hacked into the CI >> >within a very short time (the needed information is in exactly the >> >patches that currently fail to integrate). >> > >> >this cannot be possibly more effort than would be required to do >> >parallel releases, however minimal we try to make them. and it has a >> >much higher pay-off beyond the next few days. >> >> Disabling testing these modules has to be hacked into the CI. Disabling them from being compiled is a simple change in qt5.git, so it’s even easier. >> >yes, right in this second. that's not what i call a strategy. > >> And seeing that we’re having these problems again and again, I believe >> that we have a higher pay-off in the long term by removing them. They >> aren’t part of the release, they are not really maintained, so I don’t >> want us to have to deal with these modules to get our release out. >> >we already *know* that we have to do at least minimal maintenance of >them. users have *told* us so. and for that matter, it's some very >creative interpretation of the backwards compatibility promise to say >that removing entire modules doesn't violate it. we tried to weasel out >of that by saying they could continue to use the old versions with new >qt releases. we (predictably) failed at that, so we have to deliver an >alternative. > >so any reasonable calculation of pay-off assumes these modules' presence >until qt6. The question is about where they are present. They can’t be part of what we support in the future, we have already agreed on that. Consequently they are not part of what we release. > >> Like that we decouple the problems and can work on getting some source >> packages for these unsupported modules with a different time schedule. >> >why do you think that we'll *ever* have more time for that than right >now? especially given that it will be *more* total effort if we take it >out of the general process? > >and that doesn't even consider the user perspective on these pseudo >releases ... They are and should not be part of our release. They aren’t officially supported, and making them compile and offering a source tarball is merely a convenient service we can offer. The cost of them blocking our releases is what bothers me. That one is what’s expensive, not making them compile in an independent effort. Lars From oswald.buddenhagen at theqtcompany.com Thu Feb 4 14:29:18 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 14:29:18 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> Message-ID: <20160204132918.GA7252@troll08.it.local> On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote: > On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" wrote: > >so any reasonable calculation of pay-off assumes these modules' > >presence until qt6. > > The question is about where they are present. They can’t be part of > what we support in the future, we have already agreed on that. > Consequently they are not part of what we release. > we established previously that keeping them in minimal form in the releases is the overall cheapest way. it also happens to be the most user-friendly way. win-win. > >> Like that we decouple the problems and can work on getting some source > >> packages for these unsupported modules with a different time schedule. > >> > >why do you think that we'll *ever* have more time for that than right > >now? especially given that it will be *more* total effort if we take it > >out of the general process? > > > >and that doesn't even consider the user perspective on these pseudo > >releases ... > > They are and should not be part of our release. They aren’t officially > supported, and making them compile and offering a source tarball is > merely a convenient service we can offer. > this borders on mocking our "legacy" users. > The cost of them blocking our releases is what bothers me. That one is > what’s expensive, not making them compile in an independent effort. > i don't see how this sort of tactical thinking makes any sense. what does it matter even if the release is delayed by a day by that? and we've alrady spent more time discussing the matter than it would have taken simon to implement the autotest suppression logic that would solve the entire issue (for now). From Lars.Knoll at theqtcompany.com Thu Feb 4 14:39:52 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 13:39:52 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204132918.GA7252@troll08.it.local> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> <20160204132918.GA7252@troll08.it.local> Message-ID: <765ECBF4-EAB3-4E89-B985-03A2B26B7AD5@theqtcompany.com> On 04/02/16 14:29, "Releasing on behalf of Oswald Buddenhagen" wrote: >On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote: >> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >so any reasonable calculation of pay-off assumes these modules' >> >presence until qt6. >> >> The question is about where they are present. They can’t be part of >> what we support in the future, we have already agreed on that. >> Consequently they are not part of what we release. >> >we established previously that keeping them in minimal form in the >releases is the overall cheapest way. >it also happens to be the most user-friendly way. win-win. Depends on your definition of cheap. I don’t think delays to our release are cheap at all. Neither is the added stress to our engineers. > >> >> Like that we decouple the problems and can work on getting some source >> >> packages for these unsupported modules with a different time schedule. >> >> >> >why do you think that we'll *ever* have more time for that than right >> >now? especially given that it will be *more* total effort if we take it >> >out of the general process? >> > >> >and that doesn't even consider the user perspective on these pseudo >> >releases ... >> >> They are and should not be part of our release. They aren’t officially >> supported, and making them compile and offering a source tarball is >> merely a convenient service we can offer. >> >this borders on mocking our "legacy" users. How’s that? I still want to provide the source tar balls. I just don’t believe a tight coupling between those and our official release is helping anybody. > >> The cost of them blocking our releases is what bothers me. That one is >> what’s expensive, not making them compile in an independent effort. >> >i don't see how this sort of tactical thinking makes any sense. what >does it matter even if the release is delayed by a day by that? >and we've alrady spent more time discussing the matter than it would >have taken simon to implement the autotest suppression logic that would >solve the entire issue (for now). The ‘for now’ is the whole problem. In any case, the most important thing is to get things working now so we can move forward. As Jedrzej said, simply disabling the tests in qt5.git (option B) is also a short term fix, as it won’t help you for the case where the module stops compiling (as you then have to also fix all the tests). So it delays the problem and when things go wrong it’ll hit us even harder, as we then have to also fix tests. And usually that happens with time pressure. I want to get them out of the release process to remove exactly that time pressure on these modules. Cheers, Lars From oswald.buddenhagen at theqtcompany.com Thu Feb 4 15:11:15 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 15:11:15 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <765ECBF4-EAB3-4E89-B985-03A2B26B7AD5@theqtcompany.com> References: <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> <20160204132918.GA7252@troll08.it.local> <765ECBF4-EAB3-4E89-B985-03A2B26B7AD5@theqtcompany.com> Message-ID: <20160204141115.GB9366@troll08.it.local> On Thu, Feb 04, 2016 at 02:39:52PM +0100, Knoll Lars wrote: > On 04/02/16 14:29, "Releasing on behalf of Oswald Buddenhagen" wrote: > >On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote: > >> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" wrote: > >> >so any reasonable calculation of pay-off assumes these modules' > >> >presence until qt6. > >> > >> The question is about where they are present. They can’t be part of > >> what we support in the future, we have already agreed on that. > >> Consequently they are not part of what we release. > >> > >we established previously that keeping them in minimal form in the > >releases is the overall cheapest way. > > Depends on your definition of cheap. I don’t think delays to our release are cheap at all. Neither is the added stress to our engineers. > minimal delays aren't expensive, especially considering how much behind we are *already*. and with this in mind, there is no reason to stress ourselves at all. > >> They are and should not be part of our release. They aren’t > >> officially supported, and making them compile and offering a source > >> tarball is merely a convenient service we can offer. > >> > >this borders on mocking our "legacy" users. > > How’s that? I still want to provide the source tar balls. I just don’t > believe a tight coupling between those and our official release is > helping anybody. > as i said before, the fact that we are taking them out at all is already a stretch of our compatibility promise. not introducing fully avoidable obstacles is the least we can do to keep the users happy. > >> The cost of them blocking our releases is what bothers me. That one is > >> what’s expensive, not making them compile in an independent effort. > >> > >i don't see how this sort of tactical thinking makes any sense. what > >does it matter even if the release is delayed by a day by that? > >and we've alrady spent more time discussing the matter than it would > >have taken simon to implement the autotest suppression logic that would > >solve the entire issue (for now). > > The ‘for now’ is the whole problem. > that's not your argument so far at all - you were arguing for the immediate cost. the followup cost i expect is that we'll need to fix build problems from time to time, just like we had to this time. it is *very* unlikely that this will happen again within the 5.6.0 timeframe. i won't exclude the possiblity that we'll need to do a few other things to put these repos into the release, but these things would be just more of the same selective disabling of particular build/test steps, so it's not exactly rocket science. > As Jedrzej said, simply disabling the tests in qt5.git (option B) is > also a short term fix, as it won’t help you for the case where the > module stops compiling (as you then have to also fix all the tests). > So it delays the problem and when things go wrong it’ll hit us even > harder, as we then have to also fix tests. > that's entirely irrelevant if we skip tests for these modules during integration runs altogether, which is option C - the one i endorsed. we can think of re-enabling them if somebody from the community steps up and commits to maintaining them, but that's nothing i'd worry about now. From Lars.Knoll at theqtcompany.com Thu Feb 4 15:15:01 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 4 Feb 2016 14:15:01 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204141115.GB9366@troll08.it.local> References: <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> <20160204132918.GA7252@troll08.it.local> <765ECBF4-EAB3-4E89-B985-03A2B26B7AD5@theqtcompany.com> <20160204141115.GB9366@troll08.it.local> Message-ID: On 04/02/16 15:11, "Releasing on behalf of Oswald Buddenhagen" wrote: >On Thu, Feb 04, 2016 at 02:39:52PM +0100, Knoll Lars wrote: >> On 04/02/16 14:29, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote: >> >> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" wrote: >> >> >so any reasonable calculation of pay-off assumes these modules' >> >> >presence until qt6. >> >> >> >> The question is about where they are present. They can’t be part of >> >> what we support in the future, we have already agreed on that. >> >> Consequently they are not part of what we release. >> >> >> >we established previously that keeping them in minimal form in the >> >releases is the overall cheapest way. >> >> Depends on your definition of cheap. I don’t think delays to our release are cheap at all. Neither is the added stress to our engineers. >> >minimal delays aren't expensive, especially considering how much behind >we are *already*. >and with this in mind, there is no reason to stress ourselves at all. > >> >> They are and should not be part of our release. They aren’t >> >> officially supported, and making them compile and offering a source >> >> tarball is merely a convenient service we can offer. >> >> >> >this borders on mocking our "legacy" users. >> >> How’s that? I still want to provide the source tar balls. I just don’t >> believe a tight coupling between those and our official release is >> helping anybody. >> >as i said before, the fact that we are taking them out at all is already >a stretch of our compatibility promise. not introducing fully avoidable >obstacles is the least we can do to keep the users happy. > >> >> The cost of them blocking our releases is what bothers me. That one is >> >> what’s expensive, not making them compile in an independent effort. >> >> >> >i don't see how this sort of tactical thinking makes any sense. what >> >does it matter even if the release is delayed by a day by that? >> >and we've alrady spent more time discussing the matter than it would >> >have taken simon to implement the autotest suppression logic that would >> >solve the entire issue (for now). >> >> The ‘for now’ is the whole problem. >> >that's not your argument so far at all - you were arguing for the >immediate cost. >the followup cost i expect is that we'll need to fix build problems from >time to time, just like we had to this time. it is *very* unlikely that >this will happen again within the 5.6.0 timeframe. >i won't exclude the possiblity that we'll need to do a few other things >to put these repos into the release, but these things would be just more >of the same selective disabling of particular build/test steps, so it's >not exactly rocket science. > >> As Jedrzej said, simply disabling the tests in qt5.git (option B) is >> also a short term fix, as it won’t help you for the case where the >> module stops compiling (as you then have to also fix all the tests). >> So it delays the problem and when things go wrong it’ll hit us even >> harder, as we then have to also fix tests. >> >that's entirely irrelevant if we skip tests for these modules during >integration runs altogether, which is option C - the one i endorsed. Ok, I thought you wanted option B. Option C is something we can probably live with, at least for now. But it does have the problem that we will loose all information about how well that module is working in the longer term. Cheers, Lars > >we can think of re-enabling them if somebody from the community steps up >and commits to maintaining them, but that's nothing i'd worry about now. >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing From oswald.buddenhagen at theqtcompany.com Thu Feb 4 17:48:30 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 4 Feb 2016 17:48:30 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: References: <20160204112342.GF28951@troll08.it.local> <132BF606-FE97-4064-B899-FD0003DAD5EA@theqtcompany.com> <20160204115005.GA21907@troll08.it.local> <034BA90C-7EB6-4445-A8AF-A5925882CCA2@theqtcompany.com> <20160204122510.GD21907@troll08.it.local> <20160204132918.GA7252@troll08.it.local> <765ECBF4-EAB3-4E89-B985-03A2B26B7AD5@theqtcompany.com> <20160204141115.GB9366@troll08.it.local> Message-ID: <20160204164830.GB30275@troll08.it.local> On Thu, Feb 04, 2016 at 03:15:01PM +0100, Knoll Lars wrote: > On 04/02/16 15:11, Oswald Buddenhagen wrote: > >that's entirely irrelevant if we skip tests for these modules during > >integration runs altogether, which is option C - the one i endorsed. > > Ok, I thought you wanted option B. Option C is something we can > probably live with, at least for now. But it does have the problem > that we will loose all information about how well that module is > working in the longer term. > that's why i suggested that we leave the tests on in state builds (where they don't block integration). we can arrange that later. From thiago.macieira at intel.com Fri Feb 5 00:17:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Feb 2016 15:17:03 -0800 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> Message-ID: <7524652.avZNMz6ZR5@tjmaciei-mobl4> On quinta-feira, 4 de fevereiro de 2016 11:43:12 PST Robin Burchell wrote: > Hi, > > Well written mail :) Hello all Agreed, thanks for bringing this up. > On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote: > > From time to time we are deprecating/removing a module. Great it is > > normal > > > > that certain technologies fade out. We announce that the module is > > deprecated and removed, then people start complaining, it is also normal. > > Nobody want to upgrade software because it is costly. Then we get scared > > and we say, "ah don't worry it is deprecated, but we will keep it working > > for a while and we will still ship packages with it...". That in my > > opinion is not normal. > > Agreed. If a spade is a spade, call it a spade. If nobody is working on > it, and nobody will be working on it for valid reasons (whether > technical like QtQuick1, or business in the case of QtWebkit where AIUI > there simply aren't enough resources to dedicate the required effort to > it), then it's deprecated, whether or not that's a popular announcement > to make. I'd like to make a distinction here between deprecated and removed. We have five states, which I described more in detail in some blog back in 2011 or 2012, which you can find for more info: 1. Active 2. Maintained 3. Done 4. Deprecated 5. Removed Deprecated means "don't write new code using this, begin porting away from it as it will be removed in the future", whereas "removed" means "breaks unless you port away". Now, we can have variances of deprecated, which I will not go into. Specifically for modules, we promised this: qtwebkit Deprecated qtscript Deprecated qtquick1 Removed We also tried to say that Deprecated modules would work with new releases, but we clearly failed to do that because of our extensive use of private APIs across modules, in which I include our entire buildsystem starting at load(qt_build_config). > > I see a few options: > > A. we ask someone to maintain a deprecated / removed module, but then I > > guess it would be better to change the status to Done. > > I don't think this is in practice an option, because in reality this is > little more than life support. It basically means "we'll keep the lights > on and fix compilation/test failures but nothing else" which in turn > leads to the reputation hit that I already mentioned. Agreed, this is not feasible. Whether we would call this "Done" or whether it's a sublevel like "Deprecated with Support", is a discussion for another day. Skipping B because I agree with Robin's arguments. > > C. we can disable tests completely for such modules. So we would assume > > that if they compile then they are good enough. You know what are the > > consequences of it. > > Yes, but it also reflects reality: it's deprecated. There's nobody > working on it. If nobody is working on it, there should be no real > change going on in the module itself, and the deprecation has already > indicated that we don't want to spend resources on testing and > maintaining it. So this sounds better, since it allows trivial fixes > without blocking either those fixes or releasing efforts. I think this level should be applied to the modules in Deprecated state. The minimum we need is the ability to say "it compiles". > It does have the obvious downside of potential breakage. Perhaps staging > should be restricted to either someone who wants to volunteer to > undertake that for that module (or maintainers, collectively), who would > be responsible for vetting changes to make sure they _are_ really just > simple compilation fix-type things. Agreed on the procedure. We should also be very aware of the fact that disabling tests completely means we could introduce breakages we won't find until a user hits it. I would counter-argue by saying that most such issues won't be caused by changes in the deprecated module, but by those in other module on which it depends. That means a failure of testing and a regular bug report. It also means a willingness to investigate whether the regression reported against a deprecated module was caused by changes in other modules. > > D. we can avoid shipping them completely > > Honestly, I'd prefer this. Deprecated (to me) means zero effort > expended, but I guess there was already a decision taken to reverse this > for reasons I'm too lazy to go find out right now. I guess a combination > of C & D could also be an option: don't ship them, and disable testing > to enable easy fixes from whoever wants to volunteer to go make them. I wouldn't prefer this. This is only possible for Removed modules (by definition, actually). Trying to make Deprecated = Removed will simply anger our users, especially those of qtwebkit, and make fools of us because we've been promising to keep compatibility. We may as well call the next release after that 6.0. So I would say we *have* to bite the bullet and at the very least keep those modules compiling. It adds work, but it's work we have to do. We only need to find a way to do that work without introducing burden at the wrong times. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at theqtcompany.com Fri Feb 5 08:42:12 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 5 Feb 2016 08:42:12 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <20160204164830.GB30275@troll08.it.local> References: <20160204112342.GF28951@troll08.it.local> <20160204164830.GB30275@troll08.it.local> Message-ID: <2623945.T6CLs7MTX2@42> On Thursday 04 of February 2016 17:48:30 Oswald Buddenhagen wrote: > On Thu, Feb 04, 2016 at 03:15:01PM +0100, Knoll Lars wrote: > > On 04/02/16 15:11, Oswald Buddenhagen wrote: > > >that's entirely irrelevant if we skip tests for these modules during > > >integration runs altogether, which is option C - the one i endorsed. > > > > Ok, I thought you wanted option B. Option C is something we can > > probably live with, at least for now. But it does have the problem > > that we will loose all information about how well that module is > > working in the longer term. > > that's why i suggested that we leave the tests on in state builds (where > they don't block integration). we can arrange that later. > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing Ok, this is the action that we took yesterday (option C). Simon marked QtQtuick1 module in CI as one without tests (Thanks!) Cheers, Jędrek From jedrzej.nowacki at theqtcompany.com Fri Feb 5 08:56:47 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 5 Feb 2016 08:56:47 +0100 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <7524652.avZNMz6ZR5@tjmaciei-mobl4> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <7524652.avZNMz6ZR5@tjmaciei-mobl4> Message-ID: <1535773.7qiVEd9YEq@42> On Thursday 04 of February 2016 15:17:03 Thiago Macieira wrote: > On quinta-feira, 4 de fevereiro de 2016 11:43:12 PST Robin Burchell wrote: > > Hi, > > > > Well written mail :) > > Hello all > > Agreed, thanks for bringing this up. > > > On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote: > > > From time to time we are deprecating/removing a module. Great it is > > > normal > > > > > > that certain technologies fade out. We announce that the module is > > > deprecated and removed, then people start complaining, it is also > > > normal. > > > Nobody want to upgrade software because it is costly. Then we get scared > > > and we say, "ah don't worry it is deprecated, but we will keep it > > > working > > > for a while and we will still ship packages with it...". That in my > > > opinion is not normal. > > > > Agreed. If a spade is a spade, call it a spade. If nobody is working on > > it, and nobody will be working on it for valid reasons (whether > > technical like QtQuick1, or business in the case of QtWebkit where AIUI > > there simply aren't enough resources to dedicate the required effort to > > it), then it's deprecated, whether or not that's a popular announcement > > to make. > > I'd like to make a distinction here between deprecated and removed. We have > five states, which I described more in detail in some blog back in 2011 or > 2012, which you can find for more info: > 1. Active > 2. Maintained > 3. Done > 4. Deprecated > 5. Removed > > Deprecated means "don't write new code using this, begin porting away from > it as it will be removed in the future", whereas "removed" means "breaks > unless you port away". Now, we can have variances of deprecated, which I > will not go into. > > Specifically for modules, we promised this: > qtwebkit Deprecated > qtscript Deprecated > qtquick1 Removed > > We also tried to say that Deprecated modules would work with new releases, > but we clearly failed to do that because of our extensive use of private > APIs across modules, in which I include our entire buildsystem starting at > load(qt_build_config). > > > > I see a few options: > > > A. we ask someone to maintain a deprecated / removed module, but then I > > > guess it would be better to change the status to Done. > > > > I don't think this is in practice an option, because in reality this is > > little more than life support. It basically means "we'll keep the lights > > on and fix compilation/test failures but nothing else" which in turn > > leads to the reputation hit that I already mentioned. > > Agreed, this is not feasible. Whether we would call this "Done" or whether > it's a sublevel like "Deprecated with Support", is a discussion for another > day. > > Skipping B because I agree with Robin's arguments. > > > > C. we can disable tests completely for such modules. So we would assume > > > that if they compile then they are good enough. You know what are the > > > consequences of it. > > > > Yes, but it also reflects reality: it's deprecated. There's nobody > > working on it. If nobody is working on it, there should be no real > > change going on in the module itself, and the deprecation has already > > indicated that we don't want to spend resources on testing and > > maintaining it. So this sounds better, since it allows trivial fixes > > without blocking either those fixes or releasing efforts. > > I think this level should be applied to the modules in Deprecated state. The > minimum we need is the ability to say "it compiles". > > > It does have the obvious downside of potential breakage. Perhaps staging > > should be restricted to either someone who wants to volunteer to > > undertake that for that module (or maintainers, collectively), who would > > be responsible for vetting changes to make sure they _are_ really just > > simple compilation fix-type things. > > Agreed on the procedure. > > We should also be very aware of the fact that disabling tests completely > means we could introduce breakages we won't find until a user hits it. I > would counter-argue by saying that most such issues won't be caused by > changes in the deprecated module, but by those in other module on which it > depends. That means a failure of testing and a regular bug report. > > It also means a willingness to investigate whether the regression reported > against a deprecated module was caused by changes in other modules. > > > > D. we can avoid shipping them completely > > > > Honestly, I'd prefer this. Deprecated (to me) means zero effort > > expended, but I guess there was already a decision taken to reverse this > > for reasons I'm too lazy to go find out right now. I guess a combination > > of C & D could also be an option: don't ship them, and disable testing > > to enable easy fixes from whoever wants to volunteer to go make them. > > I wouldn't prefer this. This is only possible for Removed modules (by > definition, actually). > > Trying to make Deprecated = Removed will simply anger our users, especially > those of qtwebkit, and make fools of us because we've been promising to keep > compatibility. We may as well call the next release after that 6.0. > > So I would say we *have* to bite the bullet and at the very least keep those > modules compiling. It adds work, but it's work we have to do. We only need > to find a way to do that work without introducing burden at the wrong > times. Yes, I realized after sending, that mixing in one email deprecated and removed, is not a good idea... Anyway it seems that we agreed on this support level from the CI point of view: 1. Active -> Built encouraged, testing encouraged 2. Maintained -> built and tested 3. Done -> built and tested 4. Deprecated -> built 5. Removed -> built Thanks! Jędrek From Lars.Knoll at theqtcompany.com Fri Feb 5 09:01:26 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 5 Feb 2016 08:01:26 +0000 Subject: [Releasing] Deprecation - we are doing that wrong In-Reply-To: <7524652.avZNMz6ZR5@tjmaciei-mobl4> References: <2431276.mndH6jJ9gQ@42> <1454582592.349182.511719306.304890C7@webmail.messagingengine.com> <7524652.avZNMz6ZR5@tjmaciei-mobl4> Message-ID: Hi Thiago, On 05/02/16 00:17, "Releasing on behalf of Thiago Macieira" wrote: >On quinta-feira, 4 de fevereiro de 2016 11:43:12 PST Robin Burchell wrote: >> Hi, >> >> Well written mail :) > >Hello all > >Agreed, thanks for bringing this up. > >> On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote: >> > From time to time we are deprecating/removing a module. Great it is >> > normal >> > >> > that certain technologies fade out. We announce that the module is >> > deprecated and removed, then people start complaining, it is also normal. >> > Nobody want to upgrade software because it is costly. Then we get scared >> > and we say, "ah don't worry it is deprecated, but we will keep it working >> > for a while and we will still ship packages with it...". That in my >> > opinion is not normal. >> >> Agreed. If a spade is a spade, call it a spade. If nobody is working on >> it, and nobody will be working on it for valid reasons (whether >> technical like QtQuick1, or business in the case of QtWebkit where AIUI >> there simply aren't enough resources to dedicate the required effort to >> it), then it's deprecated, whether or not that's a popular announcement >> to make. > >I'd like to make a distinction here between deprecated and removed. We have >five states, which I described more in detail in some blog back in 2011 or >2012, which you can find for more info: > 1. Active > 2. Maintained > 3. Done > 4. Deprecated > 5. Removed > >Deprecated means "don't write new code using this, begin porting away from it >as it will be removed in the future", whereas "removed" means "breaks unless >you port away". Now, we can have variances of deprecated, which I will not go >into. Yes, we originally had states 1-4, but we’re adding 5 now as well. > >Specifically for modules, we promised this: > qtwebkit Deprecated > qtscript Deprecated > qtquick1 Removed No, we also moved qtwebkit into the Removed category. We promised to keep qtscript in Deprecated though. Removed means the module is not part of the official release anymore, and we’re not providing it as part of the binary packages. We however agreed that we will keep those modules compiling against the latest Qt version, as a service to people that still haven’t been able to port away from them. > >We also tried to say that Deprecated modules would work with new releases, but >we clearly failed to do that because of our extensive use of private APIs >across modules, in which I include our entire buildsystem starting at >load(qt_build_config). I think qtscript is still working fine, so the statement above is not quite true. Both qtwebkit and qtquick1 are still compiling and (apart from someone stepping up and doing further testing), that’s about what we can do for these modules. > >> > I see a few options: >> > A. we ask someone to maintain a deprecated / removed module, but then I >> > guess it would be better to change the status to Done. >> >> I don't think this is in practice an option, because in reality this is >> little more than life support. It basically means "we'll keep the lights >> on and fix compilation/test failures but nothing else" which in turn >> leads to the reputation hit that I already mentioned. > >Agreed, this is not feasible. Whether we would call this "Done" or whether >it's a sublevel like "Deprecated with Support", is a discussion for another >day. > >Skipping B because I agree with Robin's arguments. > >> > C. we can disable tests completely for such modules. So we would assume >> > that if they compile then they are good enough. You know what are the >> > consequences of it. >> >> Yes, but it also reflects reality: it's deprecated. There's nobody >> working on it. If nobody is working on it, there should be no real >> change going on in the module itself, and the deprecation has already >> indicated that we don't want to spend resources on testing and >> maintaining it. So this sounds better, since it allows trivial fixes >> without blocking either those fixes or releasing efforts. > >I think this level should be applied to the modules in Deprecated state. The >minimum we need is the ability to say "it compiles". Deprecated is still supported, but we urge people to port away from it. So we do currently have CI including auto tests enabled for qtscript (but we might be a bit more lax about marking something as an expected failure). > >> It does have the obvious downside of potential breakage. Perhaps staging >> should be restricted to either someone who wants to volunteer to >> undertake that for that module (or maintainers, collectively), who would >> be responsible for vetting changes to make sure they _are_ really just >> simple compilation fix-type things. > >Agreed on the procedure. > >We should also be very aware of the fact that disabling tests completely means >we could introduce breakages we won't find until a user hits it. I would >counter-argue by saying that most such issues won't be caused by changes in >the deprecated module, but by those in other module on which it depends. That >means a failure of testing and a regular bug report. > >It also means a willingness to investigate whether the regression reported >against a deprecated module was caused by changes in other modules. Yes, this is fine for Removed modules. We check that they still compile, but nothing else. > >> > D. we can avoid shipping them completely >> >> Honestly, I'd prefer this. Deprecated (to me) means zero effort >> expended, but I guess there was already a decision taken to reverse this >> for reasons I'm too lazy to go find out right now. I guess a combination >> of C & D could also be an option: don't ship them, and disable testing >> to enable easy fixes from whoever wants to volunteer to go make them. > >I wouldn't prefer this. This is only possible for Removed modules (by >definition, actually). > >Trying to make Deprecated = Removed will simply anger our users, especially >those of qtwebkit, and make fools of us because we've been promising to keep >compatibility. We may as well call the next release after that 6.0. Again, we agreed that qtwebkit is being removed from 5.6, not that we keep it around in a deprecated state (it was marked as Deprecated in 5.5). > >So I would say we *have* to bite the bullet and at the very least keep those >modules compiling. It adds work, but it's work we have to do. We only need to >find a way to do that work without introducing burden at the wrong times. Yes, we’ll keep webkit and quick1 compiling, but they are still removed from the official release. But we’ll provide source packages (in an unsupported folder or similar) for them that you can download and compile yourself. Cheers, Lars From jani.heikkinen at theqtcompany.com Mon Feb 8 13:55:42 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 8 Feb 2016 12:55:42 +0000 Subject: [Releasing] Qt 5.7 new features: MAINTAINERS, your input needed! Message-ID: Hi all, Feature Freeze has been in effect a week but new features page(https://wiki.qt.io/New_Features_in_Qt_5.7) needs still some updates. Maintainers: please add missing items there as soon as possible, it would be really good to have this "ready" before Alpha release br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Fri Feb 12 13:49:37 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 12 Feb 2016 12:49:37 +0000 Subject: [Releasing] New Qt 5.6.0 RC snapshot available, please test Message-ID: Hi all, We have finally packages for testing, Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src Unfortunately these packages are from a bit old qt5.git integration (https://codereview.qt-project.org/#/c/147715/) so latest changes from '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from the packages, sorry about that! We are trying to release RC as soon as possible so it is really important to test these packages now to see if there is still something to be fixed before we can release the RC. Current RC blockers are here: https://bugreports.qt.io/issues/?filter=17225 .Please make sure all blocker are visible here (but remember, just a real blockers anymore!). And please start creating changelogs for final release now if not already started. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Fri Feb 12 16:51:14 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Fri, 12 Feb 2016 15:51:14 +0000 Subject: [Releasing] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: References: Message-ID: Hi, Looking at http://wiki.qt.io/New_Features_in_Qt_5.7 there is already a lot of content, but nothing is listed under the following modules: * Qt Core * Qt GUI * Qt Network * Qt Widgets * Qt Test * Qt WebView * Qt Multimedia * Qt Positioning * Qt Location For some of these it may be that there really is nothing so big that it should be mentioned in the list of most important new features, but in some of these there certainly are items to mention. We are soon approaching Qt 5.7 Alpha by which time we should be able to communicate to the users what is new and exciting in Qt 5.7. Maintainers, please update the list for your modules or in case there is nothing important, delete your module from the list. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Heikkinen Jani Sent: maanantaina 8. helmikuuta 2016 14.56 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! Importance: High Hi all, Feature Freeze has been in effect a week but new features page(https://wiki.qt.io/New_Features_in_Qt_5.7) needs still some updates. Maintainers: please add missing items there as soon as possible, it would be really good to have this "ready" before Alpha release br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Fri Feb 12 17:58:13 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 12 Feb 2016 17:58:13 +0100 Subject: [Releasing] HEADS UP: Qt 5.7 branching ongoing Message-ID: <20160212165813.GB20706@troll08.it.local> with some rather significant delay, the 5.7 branch is now available. please start using it for new changes intented for the Qt 5.7 release. we will downmerge dev to 5.7 the last time in a few days - i don't know any particular date, but it may be *quite* soon, as we're running late. it's recommended that you send retargeting requests for pending changes on dev meant for 5.7 to me immediately. if the changes still integrate on dev before monday, that's fine. From tuukka.turunen at theqtcompany.com Sat Feb 13 08:12:24 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sat, 13 Feb 2016 07:12:24 +0000 Subject: [Releasing] [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: <201602121845.06019.marc.mutz@kdab.com> References: , <201602121845.06019.marc.mutz@kdab.com> Message-ID: <59E7620E-C1A3-4D39-B7C9-675226FA58EE@theqtcompany.com> Hi, Idea is the same as with earlier releases, i.e. to mention only the most important features from user's viewpoint. Automatically generated list of all commits typically does not work even for the full change log, because it contains also unnecessary items. For the high level feature list it is often a large number of commits that together build a new feature. Please check the earlier releases' wiki entries to see what we are targeting to have. Yours, -- Tuukka > Marc Mutz kirjoitti 12.2.2016 kello 18.35: > >> On Friday 12 February 2016 16:51:14 Turunen Tuukka wrote: >> Maintainers, please update the list for your modules or in case there is >> nothing important, delete your module from the list. > > Is there any particular reason this needs to be hand-edited instead of being > automatically generated from [ChangeLog] commits? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts From oswald.buddenhagen at theqtcompany.com Wed Feb 17 19:02:50 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 17 Feb 2016 19:02:50 +0100 Subject: [Releasing] [Development] HEADS UP: Qt 5.7 branching ongoing In-Reply-To: <20160212165813.GB20706@troll08.it.local> References: <20160212165813.GB20706@troll08.it.local> Message-ID: <20160217180249.GA32311@troll08.it.local> the downmerge is now done (*). that means that 5.7 is now finally properly feature-frozen, and dev is undisputably open for new features. that means that if you integrate something on dev now, it won't be in 5.7 - cherry-picks require special negotiation (with ME!) and earn you some Very Stern Words. as usual. you may still make retargeting requests for pending changes. as usual. (*) qtbase's and qtwebengine's merges are currently integrating. that means that dev is already open, but the content is not in 5.7 yet. On Fri, Feb 12, 2016 at 05:58:13PM +0100, Oswald Buddenhagen wrote: > with some rather significant delay, the 5.7 branch is now available. > please start using it for new changes intented for the Qt 5.7 release. > > we will downmerge dev to 5.7 the last time in a few days - i don't know > any particular date, but it may be *quite* soon, as we're running late. > it's recommended that you send retargeting requests for pending changes > on dev meant for 5.7 to me immediately. if the changes still integrate > on dev before monday, that's fine. From jani.heikkinen at theqtcompany.com Fri Feb 19 11:42:30 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 19 Feb 2016 10:42:30 +0000 Subject: [Releasing] Qt 5.6.0 missing change files Message-ID: Hi all, We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of next week. Final is targeted to be released within 2 weeks as well so we need to get all change files done & in before it. Following change files are still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsensors qtsvg qttranslations qttools qtwayland qtwaylandqtwebchannel qtwebsockets qtx11extras qtxmlpatterns Maintainers, make sure needed change files are done & in before wed 24th Feb br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Tue Feb 23 16:27:09 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 23 Feb 2016 15:27:09 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 23.2.2016 Message-ID: Firstly, sorry that I forgot to send the invitation for today's meeting! Meeting minutes from Qt Release Team meeting 23rd February 2016 Qt 5.6.0 status: - rc released today, see http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/ - Target to get Qt 5.6.0 Final out Thu 3rd March 2016 * Hoping RC is good enough for making that happen - Some change files still missing, we need to get those really soon to be able to keep the target schedule * See broken links from http://wiki.qt.io/Change-files-in-Qt-5.6.0 Qt 5.7 status: - Alpha content should be in place now * Just need to get qt5.git integration + qt5 merge from '5.6' to '5.7' succeed. New try ongoing, see https://codereview.qt-project.org/#/c/149978/ - When qt5.git integration succeed we can export src packages from coin & verify the packages. - Target is to release Alpha during this week, let's see if we can make it happen Next meeting Tue 1st March 16:00 CET Irc log below: [17:00:27] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:29] jaheikki3: pong [17:02:33] Time to start qt release team meeting [17:02:40] On agenda today: [17:02:45] qt5.6 status [17:02:52] qt 5.7 status [17:03:05] Any additional items to the agenda? [17:04:50] lets start from qt5.6 status [17:05:07] rc released today, jippii! [17:05:35] http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/ [17:06:19] It seems my mail to announce at qt-project.org is stuck somewhere, at least I haven't seen it (but I sent it :) ) [17:06:46] But rc is released and now we are waiting feedback [17:08:30] Hoping RC is good enough & we don't need to take new fixes in anymore. Just missing change files (many broken links still in http://wiki.qt.io/Change-files-in-Qt-5.6.0) + some documentation updates [17:09:17] That way we could keep the estimated schedule, see http://wiki.qt.io/Qt-5.6-release (target to get final out 3rd march) [17:09:29] Any comments / questions? [17:11:38] Ok, then qt5.7 status [17:12:02] According to my understanding we should have Alpha content pretty much in place [17:12:41] We just need to get qt5.git integration (&qt5 merge from '5.6' -> '5.7') done [17:13:23] New try is ongoing, see https://codereview.qt-project.org/#/c/149978/ [17:14:09] When that succeed we can do the src export & if package seems to be good enough we can but Alpha out [17:14:48] Target was to get Alpha out during this week. It will be tight but still possible. [17:15:01] Any comments or questions? [17:16:30] (seems to be quite quiet today, I just noticed I forgot to sent meeting invitation ;) ) [17:17:43] I think it was all at this time. Let's have new meeting Tue 1st March at this same time. Hoping we can give 'go' for Qt 5.6.0 there [17:17:56] bye [17:19:51] bye From jani.heikkinen at theqtcompany.com Wed Feb 24 07:57:43 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 24 Feb 2016 06:57:43 +0000 Subject: [Releasing] Qt 5.6.0 missing change files In-Reply-To: References: Message-ID: Hi all, We really need these during this week! Still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsvg qttranslations qttools qtwayland qtwebchannel qtwebsockets qtx11extras qtxmlpatterns So no progress since last week! br, Jani ________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 19. helmikuuta 2016 12:42 Vastaanottaja: development at qt-project.org Kopio: releasing at qt-project.org Aihe: Qt 5.6.0 missing change files Hi all, We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of next week. Final is targeted to be released within 2 weeks as well so we need to get all change files done & in before it. Following change files are still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsensors qtsvg qttranslations qttools qtwayland qtwaylandqtwebchannel qtwebsockets qtx11extras qtxmlpatterns Maintainers, make sure needed change files are done & in before wed 24th Feb br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Wed Feb 24 09:09:01 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 24 Feb 2016 09:09:01 +0100 Subject: [Releasing] [Development] Qt 5.6.0 missing change files In-Reply-To: References: Message-ID: <3488012.FCQKtVoujY@42> On Wednesday 24 of February 2016 06:57:43 Heikkinen Jani wrote: > Hi all, > We really need these during this week! > Still missing: (...) > (qtenginio) No big changes > (qtscript) No big changes > qtsvg No big changes > qtwebchannel No big changes > qtwebsockets No big changes > qtx11extras No changes (only version was bumped) > qtxmlpatterns No big changes Maybe it is wroth to have a default fall-back to an "empty" changelog? Something that mentions minor code and docs cleanups plus small bug fixes? Cheers, Jędrek