Re: [Development] CI problem
Hi, CI is working again. We had some issues with database, but those are fixed now. Thanks for your patience! Br Heikki From: Heikki Halmet Sent: tiistai 15. lokakuuta 2019 17.02 To: development@qt-project.org Subject: CI problem Hi, We have problems in CI. Integrations don't get VM's for some reason. Hopefully we'll solve this out soon as possible. Ystävällisin terveisin / Kind regards, Heikki Halmet Software Engineer | CI Lead Release and Test Automation | CI Team The Qt Company | Finland | Oulu ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] CI problem
Hi, We have problems in CI. Integrations don't get VM's for some reason. Hopefully we'll solve this out soon as possible. Ystävällisin terveisin / Kind regards, Heikki Halmet Software Engineer | CI Lead Release and Test Automation | CI Team The Qt Company | Finland | Oulu ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Eliminate soft branching phase from release process
Kari Oikarinen (Friday, October 11, 2019 3:04 PM) wrote: >>> I want to propose eliminating soft branching phase and instead use >>> the creation of the branch as a cut-off for feature freeze (or bug >>> fixes for a patch release). Frederik already alluded that there has >>> been some discussion about making this change in the email about the >>> final downmerge to 5.13.2. >>> >>> Right now a week before feature freeze the new branch is created and >>> the release manager sends a heads-up mail that tells people to >>> finish their changes within a week or retarget them to the new >>> branch. Then after the week is up the original branch is merged into >>> the new branch. This is called a "downmerge", since it is in the >>> opposite direction compared to the usual merges that go "up" to >>> newer releases. Once the downmerge is done, branching is considered >>> complete and feature freeze is in effect. >>> >>> Similar week of soft branching is also involved when patch level >>> branches are created. >>> >>> As far as I can tell, the major motivation for providing this week >>> of soft branching is to allow people to finish their last changes >>> without needing to retarget the change to a new branch. Retargeting >>> of a large number of changes would also have provided a large amount >>> of work to Gerrit admins, since on our old Gerrit retargeting the >>> change needed admin rights. And of course admin response time would >>> have served as a bottleneck to work. >>> >>> Nowadays everyone can however move their own changes over to a new >>> branch. None the less, they then need to get re-approved, which can be a hassle. Ossi provided two more reasons for it: >> the reason is that the huge CI delay makes it impractical to know >> whether a change will still land in time for branch creation. We need to distinguish two "CI delay" cases here: one is the per-attempt delay (it's several hours); the other is the delay from getting +2 to having one of those attempts succeed, which can take days. Folk need at least the former's warning of the point when they must switch branches and life would be easier if they had the latter's warning. In particular, when a change is approved before feature-freeze but Coin has been flaking on it repeatedly (without it being implicated as the cause of that flakiness), do we really want to hold it out of the release ? >> also, people just don't pay attention to the branching announcements >> in real time. That can be solved by competent communication - general announcement of the schedule a week in advance, final warning about a day before, clear announcement as soon as the deed is done. Those targetting the new branch then know to hold off on staging for the last Coin-attempt cycle before branching. >> so the alternatives to soft branching are >> a) restricting the source branch before branching (which is obviously >> counterproductive) or If the duration is short, the counterproductivity is limited. We only really need to restrict for one Coin-attempt (albeit a conservative estimate at the slowest attempt). >> b) accepting the need for a significant number of cherry-picks (which >> are a hassle to make, and an annoyance in the resulting git history). Do we have statistics on how many commits Coin typically integrates to dev in a day ? (Ideally from the weeks around an actual branching.) I don't like cherry-picks, but if the numbers are modest we can live with it. Back to Kari: >>> So as our tools have improved, I see a chance to simplify our >>> processes as well. >>> >>> So instead of the soft branching process I propose the following: >>> >>> - A week before feature freeze date release manager sends a reminder >>> email about it. This provides the same useful warning as the >>> initiation of soft branching has so far. We should do this anyway ! (... and I imagine we do.) >>> - On feature freeze day release team creates the new branch. They send >>> an email to development list informing people about the feature >>> freeze being in effect. Send a mail a Coin-cycle before branching to say it's imminent. As soon as the branch exists, announce its existence. >>> - If your change did not make it into dev before the new branch was >>> created, it did not make the feature freeze cut. This is problematic when the reason it didn't get through was that Coin was flaking out, which it does all too often. That can be addressed by making (well-defined, limited) provision for a change that was already approved before branching to be allowed to move onto the new branch to get integration sorted out, if the only problem is Coin flaking out. We would need to think carefully about the rules for that, or feature freeze could end up slushy. >>> If it is a bug fix that should go to the next release still, you >>> need to move it to the new branch. If the change happened to be >>> integrated after branch creation but before you noticed, you need >>> to
Re: [Development] Proposal: Eliminate soft branching phase from release process
On Tue, Oct 15, 2019 at 08:38:30AM +, Liang Qi wrote: 2. patch releases, 1st one and others, for the first one, like 5.14.0 perhaps similar story like above. Anyway, for the patch releases, if the changes missed this release, but still could happen in next. So I think it’s better to remove the one week soft branching phase. i strongly recommend against having different schemes for minor and release branches. some people find it hard enough to know what branches are in cherry-pick mode, and adding more policy variations is not going to help. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Eliminate soft branching phase from release process
On Mon, Oct 14, 2019 at 01:40:48PM +, Kari Oikarinen wrote: On 12.10.2019 14.14, Oswald Buddenhagen wrote: > On Fri, Oct 11, 2019 at 12:04:20PM +, Kari Oikarinen wrote: >> As far as I can tell, the major motivation for providing this week >> of >> soft branching is to allow people to finish their last changes without >> needing to retarget the change to a new branch. >> > no, it's not. > the reason is that the huge CI delay makes it impractical to know > whether a change will still land in time for branch creation. also, > people just don't pay attention to the branching announcements in real > time. > so the alternatives to soft branching are a) restricting the source > branch before branching (which is obviously counterproductive) or b) > accepting the need for a significant number of cherry-picks (which are a > hassle to make, and an annoyance in the resulting git history). What I'm thinking of is on the b) side of things. But I'm not sure why the amount of cherry-picks would be a "significant number"? it's more than a handful, so it's significant. that's because every cherry-pick potentially causes CI load (if it doesn't end up in a bigger CI batch), requires the usual repetitive re-staging ritual, and then causes confusion when someone tries to actually make sense of the history. When branching out a minor branch, new features that miss the branching deadline miss the feature freeze. They don't need to be cherry-picked. in practice, there are always last-minute additions, usually with pre-approval for going into the next release. Wouldn't the category of bug fixes that are not appropriate to the older stable branch but should happen in a feature freezed branch be pretty narrow as well? bugfixes to new features are actually rather common. it's what this "stabilization" thing is all about. But anyone who wants to *actually* target the old branch needs to wait for the downmerge to pass. as you found out yourself, that's a non-usecase. the gist is that this somewhat complicated downmerge process exists for good reasons. it shifts the "logistical" load of dealing with the branching from every contributor to the few people involved in the branch management. history (now found via browsing archives; it appears impossible to google that message without putting the exact subject in quotes): https://lists.qt-project.org/pipermail/releasing/2014-August/001804.html there appears to be no other public list activity related to this. apparently, everything happened on irc. the previous installment of evolving policy was here: https://lists.qt-project.org/pipermail/releasing/2014-February/001618.html (that's essentially what you want to go back to). as you can see from the dates, it took us a single feature release to conclude that another change was necessary. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Eliminate soft branching phase from release process
We are using soft branching phase for two categories: 1. feature frozen or minor branch, like dev to 5.14, many new changes are targeting 5.14 release, but happened in dev branch, and not easy to be integrated or verified soon. the one week soft branching phase could help bit here. 2. patch releases, 1st one and others, for the first one, like 5.14.0 perhaps similar story like above. Anyway, for the patch releases, if the changes missed this release, but still could happen in next. So I think it’s better to remove the one week soft branching phase. And for the 1st case, if we want to the "soft branching phase”, we could also find some solution for it, perhaps like some feature branches and pre-checking things. Provisioning changes and coin update(perhaps other hardware or IT issues) also could affect the whole process. A better plan, not having too many things in the short one week for feature frozen period, is perhaps needed. —Liang > On 11 Oct 2019, at 14:16, Jani Heikkinen wrote: > > +1 > > This change might also speed up patch level releases a bit > > br, > Jani > > > From: Development on behalf of Kari > Oikarinen > Sent: Friday, October 11, 2019 3:04 PM > To: Qt development mailing list > Subject: [Development] Proposal: Eliminate soft branching phase from release > process > > I want to propose eliminating soft branching phase and instead use the > creation of the branch as a cut-off for feature freeze (or bug fixes > for a patch release). Frederik already alluded that there has been > some discussion about making this change in the email about the final > downmerge to 5.13.2. > > Right now a week before feature freeze the new branch is created and > the release manager sends a heads-up mail that tells people to finish > their changes within a week or retarget them to the new branch. Then > after the week is up the original branch is merged into the new > branch. This is called a "downmerge", since it is in the opposite > direction compared to the usual merges that go "up" to newer releases. > Once the downmerge is done, branching is considered complete and > feature freeze is in effect. > > Similar week of soft branching is also involved when patch level > branches are created. > > As far as I can tell, the major motivation for providing this week of > soft branching is to allow people to finish their last changes without > needing to retarget the change to a new branch. Retargeting of a large > number of changes would also have provided a large amount of work to > Gerrit admins, since on our old Gerrit retargeting the change needed > admin rights. And of course admin response time would have served as a > bottleneck to work. > > Nowadays everyone can however move their own changes over to a new > branch. So as our tools have improved, I see a chance to simplify our > processes as well. > > So instead of the soft branching process I propose the following: > > - A week before feature freeze date release manager sends a reminder > email about it. This provides the same useful warning as the > initiation of soft branching has so far. > > - On feature freeze day release team creates the new branch. They send > an email to development list informing people about the feature > freeze being in effect. > > - If your change did not make it into dev before the new branch was > created, it did not make the feature freeze cut. If it is a bug fix > that should go to the next release still, you need to move it to the > new branch. If the change happened to be integrated after branch > creation but before you noticed, you need to cherry-pick it to the > new branch. But that should hopefully be an exception. > > - There are no more downmerges. All merges happen in the same > direction. Hopefully that makes how they happen easier to > understand. > > The same approach should be used for patch level branches as well. > > Currently there is a bit of uncertainty about when exactly the > downmerges happen, since it requires not only someone to do it, but > also CI not being active in the target branch. That's a requirement > because downmerges (if they have no conflicts) are pushed directly to > the repositories instead of going through regular CI. Eliminating them > also eliminates this irregularity. It hasn't been a big problem, but > these commits have no corresponding Gerrit changes, which has confused > people when they can't actually find the review because there wasn't > one. It can also result in broken state of code, although only rarely. > By getting rid of downmerges we eliminate the vast majority of direct > pushes (and all regularly done ones). > > Since branches can be created without waiting for idle CI, the timing > of feature freeze coming into effect could become better known in > advance. This helps in avoiding confusion about whether it's in effect > or not. > > If this is approved, I promise to
Re: [Development] Proposal: Eliminate soft branching phase from release process
On 15.10.2019 11.19, Oswald Buddenhagen wrote: > On Tue, Oct 15, 2019 at 06:16:33AM +, Kari Oikarinen wrote: >> After thinking about it again, I agree with you that it's irrelevant. >> There could be a category of changes that would need to wait and I was >> describing it. >> >> But in fact there isn't, since the branching and the associated cut-off >> has not happened yet during soft branching. So any changes that need to >> happen before the cut-off can target the old branch. Either they make >> the cut-off (are included in the downmerge) or they don't and are >> included in the next release. >> >> The period is in fact exactly the same as the week before hard branching >> would be in my proposal. >> > yep. i take that as an official retraction of the proposal. ^^ It isn't, it was just to retract this part of my reply. I think the other aspects are still worth discussing. -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Eliminate soft branching phase from release process
On Tue, Oct 15, 2019 at 06:16:33AM +, Kari Oikarinen wrote: After thinking about it again, I agree with you that it's irrelevant. There could be a category of changes that would need to wait and I was describing it. But in fact there isn't, since the branching and the associated cut-off has not happened yet during soft branching. So any changes that need to happen before the cut-off can target the old branch. Either they make the cut-off (are included in the downmerge) or they don't and are included in the next release. The period is in fact exactly the same as the week before hard branching would be in my proposal. yep. i take that as an official retraction of the proposal. ^^ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Updates on bugreports.qt.io
On 17th October the server will go offline for security updates. The downtime is estimated to last one hour and starts at 7:30am CEST. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Eliminate soft branching phase from release process
On 14.10.2019 16.40, Kari Oikarinen wrote: > > > On 12.10.2019 14.14, Oswald Buddenhagen wrote: > > On Fri, Oct 11, 2019 at 12:04:20PM +, Kari Oikarinen wrote: > > > >> Currently there is a bit of uncertainty about when exactly the > >> downmerges happen, > >> > > yes, and that's entirely fine. the whole *point* of the process is to > > make it irrelevant when it happens. if you rely on the time of the > > downmerge but are not a release manager, you're doing it wrong. > > It's not irrelevant! People who target the newly created branch should > not wait until the last minute to retarget and thus the exact point in > time does not matter to them. > > But anyone who wants to *actually* target the old branch needs to wait > for the downmerge to pass. In effect the week of soft branching means > that the old branch is temporarily closed, because the changes staged > to it actually go to the newly created branch. The problem is that to > know whether that is the case you need to either read Jani's mails or > check the history for the downmerge. (And even if you did check, are > you sure it's final?) After thinking about it again, I agree with you that it's irrelevant. There could be a category of changes that would need to wait and I was describing it. But in fact there isn't, since the branching and the associated cut-off has not happened yet during soft branching. So any changes that need to happen before the cut-off can target the old branch. Either they make the cut-off (are included in the downmerge) or they don't and are included in the next release. The period is in fact exactly the same as the week before hard branching would be in my proposal. -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
