Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
Hi, I updated https://qt-project.org/wiki/Branch-Guidelines I added the Where to push a change section I also added documentation fixes. to the list. On Friday 25 January 2013 09:37:26 Jedrzej Nowacki wrote: e. Autotests extensions and new tests should go to stable if possible. It simplify merging process. Right, autotest changes as well. because it may help to catch more regressions in the stable branch. I'm not sure it simplifies the merge process. I'd say it is quite the contrary, since tests are often added in the dev branch with new tests for the new feature. The good news is that the fixing the conflicts in tests is usually easy. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On Jan 13, 2013, at 12:39 PM, Olivier Goffart oliv...@woboq.com wrote: On Friday 11 January 2013 07:40:39 Thiago Macieira wrote: On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote: Go to stable: a. Fixes to regressions against a previous recent version of Qt. (less than 2 or 3 years old) b. Fixes in new feature introduced in the most recent minor version. c. Critical fixes (P1/P0): security, crashes or data corruption. d. Compilation fixes or adaptations required for different version of the compilers or upstream libraries. Everything else go to dev. I agree with almost all: I'd like to relax c to include Important (P2) fixes, subject to the approvers' decision. Those should happen most commonly in the first one or two patch releases (.0 and .1). Everything is already subject to approvers' decision. So specifying it is redundant. I think anyway every rules rules should tollerate exceptions. In certain cases approvers will break those rules for good reason. Example: a one-line feature that is critical for an important application may get in in a patch release. The reason why I would avoid non-regressions P2 fixes in the stable branch is that they are more risky than the others one. A new minor version gets much more QA that a patch release. (there are beta release). Also, everybody tollerates a x.y.0 to have bug, but it is really bad if we introduce more bugs in patch release. And I beleive one good way to avoid regressions in patch releases is to limit the amount of risky changes that goes it. If we tollerates P2, i'm afraid every P2 goes in, and that's most of the fixes. Do you still think the wording should include P2? We might want to tighten the rules as Qt 5 gets more mature and aim for only P0/P1. Right now, I believe fixes to P2's are still a good idea as they will improve the quality of the releases (with some risk of getting regressions). So I'm for the above list with point c being: c. Critical fixes (P1/P0): security, crashes or data corruption. P2 fixes when there is a good reason/need. Cheers, Lars -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On Friday 11 January 2013 07:40:39 Thiago Macieira wrote: On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote: Go to stable: a. Fixes to regressions against a previous recent version of Qt. (less than 2 or 3 years old) b. Fixes in new feature introduced in the most recent minor version. c. Critical fixes (P1/P0): security, crashes or data corruption. d. Compilation fixes or adaptations required for different version of the compilers or upstream libraries. Everything else go to dev. I agree with almost all: I'd like to relax c to include Important (P2) fixes, subject to the approvers' decision. Those should happen most commonly in the first one or two patch releases (.0 and .1). Everything is already subject to approvers' decision. So specifying it is redundant. I think anyway every rules rules should tollerate exceptions. In certain cases approvers will break those rules for good reason. Example: a one-line feature that is critical for an important application may get in in a patch release. The reason why I would avoid non-regressions P2 fixes in the stable branch is that they are more risky than the others one. A new minor version gets much more QA that a patch release. (there are beta release). Also, everybody tollerates a x.y.0 to have bug, but it is really bad if we introduce more bugs in patch release. And I beleive one good way to avoid regressions in patch releases is to limit the amount of risky changes that goes it. If we tollerates P2, i'm afraid every P2 goes in, and that's most of the fixes. Do you still think the wording should include P2? -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
Hi, We should finish this discussion and document the conclusion in http://qt-project.org/wiki/Branch-Guidelines ... Marc Mutz wrote: Ok, trying to summarise, I understand it this way: 1. release-critical fixes are submitted and merged to 'stable' now, 'release' later, when it exists. No-brainer fixes are also welcome. 2. bug-fixes that don't violate string or BC freezes are submitted, but NOT merged, against stable. They will be merged once RC2 is tagged and 'release' is branched off. Maintainers and other reviewers can redirect a fix to 'dev' instead, but all fixes that don't require string or BiC changes should initially be submitted to 'stable'. [Personally, I'd add that if a fix goes to 'dev' instead of 'stable', then the commit message should say why.] [snip] On Monday December 10 2012, Shaw Andy replied: I don't agree that all bug fixes should go into stable, judgement should certainly be made, but we can't just put all bug fixes blindly into stable otherwise it will probably end up as being far from stable. There are times when it would be better for a bug fix to go into dev instead of stable because it may give a much too obvious behavior change for example. On Monday 10 December 2012 12:07:21 Marc Mutz replied: I was suggesting that bug-fixes _initially_ be submitted for stable (blindly, if you will) and that review decides whether to redirect them to dev instead. So I wasn't suggesting to just put all bug fixes blindly into stable. I want to avoid them going blindly to dev, though, esp. without the commit message explaining why. One problem is that re-targeting a branch with gerrit is not working. so you need to re-submit, which is a small annoyance. Even if we do it like that we still need criterion for the reviewer to decide. And if those criterion are on the wiki, the contributor can just apply the criteria them self. And what are those criteria? When does a patch goes to dev or to stable? I suggest this: Go to stable: a. Fixes to regressions against a previous recent version of Qt. (less than 2 or 3 years old) b. Fixes in new feature introduced in the most recent minor version. c. Critical fixes (P1/P0): security, crashes or data corruption. d. Compilation fixes or adaptations required for different version of the compilers or upstream libraries. Everything else go to dev. The reason to limit to regression fixes is that if one could live few releases with a given bug, then he can still wait another 6 months for the bug fixe. That way we minimize the risks of introducing new subtle bugs in patch release. Then there is the question: What can go into Qt 4.8? Normaly, the criterias for Qt 4.8 should be the same as for the stable branch. For example, to me, small bugs like QTBUG-20403 should go to dev, and not to stable or 4.8 It would be nice to come to an agreement and write the policy on the wiki. Regards. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On 11 January 2013 15:21, Olivier Goffart oliv...@woboq.com wrote: c. Critical fixes (P1/P0): security, crashes or data corruption. Aren't important fixes (such as security fixes) good candidates for the release branch instead of stable? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On Fri, Jan 11, 2013 at 04:53:25PM +0100, Giuseppe D'Angelo wrote: On 11 January 2013 15:21, Olivier Goffart oliv...@woboq.com wrote: c. Critical fixes (P1/P0): security, crashes or data corruption. Aren't important fixes (such as security fixes) good candidates for the release branch instead of stable? olivier's summary does not consider the release branches at all. the active existence of release branches is temporary. their activation (merge from stable) needs to be announced a day or more in advance (so stuff important for the release is not still integrating to stable while the branch is updated). they get deactivated again after a release. as such, the release branch submission policy is a special case of the stable branch submission policy. the above point c is certainly a good starting point. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
-Original Message- From: development-bounces+andy.shaw=digia@qt-project.org [mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of Marc Mutz Sent: 9. desember 2012 14:23 To: development@qt-project.org Subject: Re: [Development] RFC: What constitutes a non-destabilising bug- fix? On Saturday December 8 2012, Thiago Macieira wrote: [...] We'll create the releases branch for the RC2 then. Ok, trying to summarise, I understand it this way: 1. release-critical fixes are submitted and merged to 'stable' now, 'release' later, when it exists. No-brainer fixes are also welcome. 2. bug-fixes that don't violate string or BC freezes are submitted, but NOT merged, against stable. They will be merged once RC2 is tagged and 'release' is branched off. Maintainers and other reviewers can redirect a fix to 'dev' instead, but all fixes that don't require string or BiC changes should initially be submitted to 'stable'. [Personally, I'd add that if a fix goes to 'dev' instead of 'stable', then the commit message should say why.] [snip] I don't agree that all bug fixes should go into stable, judgement should certainly be made, but we can't just put all bug fixes blindly into stable otherwise it will probably end up as being far from stable. There are times when it would be better for a bug fix to go into dev instead of stable because it may give a much too obvious behavior change for example. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On Sunday December 9 2012, Sune Vuorela wrote: On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote: On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote: 3. new features and bug-fixes that require new strings or BiC changes should be submitted to 'dev' directly. binary incompatible changes should not be submitted anywhere except for Qt6. I've asked to clarify the above. There is a special thing from now until 5.0 is out where under certain circumstances, BiC changes can happen, and should under those certain circumstances happen in all branches targetting 5.y.z. Until 5.0 is out. Find those certain circumstances and a howto in a relevant mail from the chief maintainer. Once 5.0 is out, my above sentence should apply. Sorry, I was unclear. When I say BiC/BC I meant _forward_ binary compatibility as required between point releases. Thanks for the heads-up, though. Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
Hi Andy, On Monday December 10 2012, Shaw Andy wrote: Ok, trying to summarise, I understand it this way: 1. release-critical fixes are submitted and merged to 'stable' now, 'release' later, when it exists. No-brainer fixes are also welcome. 2. bug-fixes that don't violate string or BC freezes are submitted, but NOT merged, against stable. They will be merged once RC2 is tagged and 'release' is branched off. Maintainers and other reviewers can redirect a fix to 'dev' instead, but all fixes that don't require string or BiC changes should initially be submitted to 'stable'. [Personally, I'd add that if a fix goes to 'dev' instead of 'stable', then the commit message should say why.] [snip] I don't agree that all bug fixes should go into stable, judgement should certainly be made, but we can't just put all bug fixes blindly into stable otherwise it will probably end up as being far from stable. There are times when it would be better for a bug fix to go into dev instead of stable because it may give a much too obvious behavior change for example. I was suggesting that bug-fixes _initially_ be submitted for stable (blindly, if you will) and that review decides whether to redirect them to dev instead. So I wasn't suggesting to just put all bug fixes blindly into stable. I want to avoid them going blindly to dev, though, esp. without the commit message explaining why. I agree with you otherwise. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On segunda-feira, 10 de dezembro de 2012 12.07.21, Marc Mutz wrote: I was suggesting that bug-fixes initially be submitted for stable (blindly, if you will) and that review decides whether to redirect them to dev instead. If you're a reviewer and you know you'd suggest moving it to dev, then you might as well send your own fix to dev in the first place. As I said in my earlier reply, use the grey mass :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On Saturday December 8 2012, Thiago Macieira wrote: [...] We'll create the releases branch for the RC2 then. Ok, trying to summarise, I understand it this way: 1. release-critical fixes are submitted and merged to 'stable' now, 'release' later, when it exists. No-brainer fixes are also welcome. 2. bug-fixes that don't violate string or BC freezes are submitted, but NOT merged, against stable. They will be merged once RC2 is tagged and 'release' is branched off. Maintainers and other reviewers can redirect a fix to 'dev' instead, but all fixes that don't require string or BiC changes should initially be submitted to 'stable'. [Personally, I'd add that if a fix goes to 'dev' instead of 'stable', then the commit message should say why.] 3. new features and bug-fixes that require new strings or BiC changes should be submitted to 'dev' directly. Correct? BTW: Two of the three commits that have landed in 'dev' so far are bug-fixes (one bug-fix and one tests/-only change, to be precise; the third is the addition of changes-5.1.0), which shows that the 'stable' rules seem to be interpreted too strictly, currently. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote: On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote: 3. new features and bug-fixes that require new strings or BiC changes should be submitted to 'dev' directly. binary incompatible changes should not be submitted anywhere except for Qt6. I've asked to clarify the above. There is a special thing from now until 5.0 is out where under certain circumstances, BiC changes can happen, and should under those certain circumstances happen in all branches targetting 5.y.z. Until 5.0 is out. Find those certain circumstances and a howto in a relevant mail from the chief maintainer. Once 5.0 is out, my above sentence should apply. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a non-destabilising bug-fix?
On sábado, 8 de dezembro de 2012 09.53.44, Alan Alpert wrote: This thing about the non-destabilizing bug fixes is just the release team being cautious because we don't have a release branch yet. Theoretically I'd have thought the release branch should have started for RC1 and then the release team would cherry-pick fixes into that branch. But if that's not happening then we just have the same work flow as in 4.x when there was only one master: be cautious with commits around release time. The only reason this might be perceived as a regression is that we actually have another branch that won't get into the release, allowing development to continue like we had always dreamed of. So it seems we're currently only half-way over into our new branching paradigm and that will be confusing until we shift fully. Unless I got the new paradigm wrong, in which case it's confusing now . No, you didn't. I discussed this with Lars and Tuukka yesterday before leaving for the airport. We discussed whether we should branch now at RC1, wait until RC2 or even longer. There are good arguments in both directions: - if we don't branch now, we risk destabilising changes going in, changes that should be kept back. - what's more, if we don't branch now, there's nowhere to put important bug fixes that just need a little more testing (i.e., the ones for 5.0.1) - however, if we do branch now, we create work for the release team for cherry-picking the important fixes or redirecting to the release branch. So we discussed a judgement call: to us, it looked like we'll need a lot of necessary fixes on top of RC1 -- some of which we already know, which is why we're certain there will be an RC2. If we branch now, we create a lot of additional work. The risk of a regressing change being accepted is worth the gain in workflow. We'll create the releases branch for the RC2 then. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
