[Development] [Releasing] HEADS UP: Qt 5.4 feature freeze - branch created

[Thiago Macieira]

On Sunday 10 August 2014 19:55:44 Oswald Buddenhagen wrote:
> On Sun, Aug 10, 2014 at 02:10:52PM -0300, Thiago Macieira wrote:
> > Because it changed compared to previous times. It's irrelevant that the
> > previous times required such an action for technical reasons: it happened
> > that way. Now it happened differently.
> 
> that's a fact. but given that no specific problems with doing it
> "the new way" were brought up, it's a rather useless observation.

You're missing the obvious: there was a change and people were not ready for 
it.

I'm not saying the new way is bad. In fact, aside from the commit that didn't 
compile, the procedure, as it was done, was quite good. We could even shorten 
the time required and I don't see the point of lockdowns anymore -- provided 
someone volunteers to do retargetting.

The only problem is that this was a change from the previous procedure and 
people were caught by surprise. We were expecting to be able to work on dev 
throughout the weekend, but we were only given less than 12 hours on Saturday.

> > > to me this is a rather obvious interpretation of "freeze exception",
> > > which is why it's beyond me why anyone would get upset about me NOT
> > > holding up integrations on dev even longer than planned (which would be
> > > a logical consequence of delaying the 5.4 branch creation).
> > 
> > I wouldn't be upset if you had done what you say here. You didn't.
> > 
> > You did block dev by introducing a broken change
> 
> you are entirely missing the point. you (or anybody else) was not
> supposed to stage anything on dev. if not for that mistake, you would
> have created a royal mess in the branches with to your uncoordinated
> intervention.

Which, again, is a change from previous procedure. In past times, as a member 
of the release team, I had the right to stage things past the feature freeze, 
to get things integrated that failed due to unrelated CI failures and commits 
that were granted exception from the freeze.

Again: the new procedure isn't bad. It's just different and we were unprepared.

> > and did not enable 5.4 (which should include the moving of the pending
> > changes from dev to 5.4).
> 
> at that point, a day on a weekend is hardly a relevant issue.
> especially that 5.4 doesn't integrate anyway due to no fault of mine.

It is relevant for the people who can work on Qt mostly on the weekends (like 
me). The person to blame is not relevant: 5.4 integration was blocked and 
still is, so I can't work on things right now.

Though I'll concede that it was outside your control, you expected it to work 
and s&#t happens. We learn and move on, hopefully it won't happen the next 
time.

> > > speaking of which, dev will be opened again early tuesday.
> > 
> > So it's not open.
> 
> of course not. that was part of the plan. but it will be open again
> sooner than if you got your way.

Tuesday August 12 is not sooner than Saturday August 9.

> > > fwiw, the first batch of retargetings is done. you can already stage,
> > > even though it probably won't start integrating until monday.
> > 
> > Ok, so I can get back to work around midnight Wednesday UTC. Great.
> 
> as this sounds like a complaint, one has to wonder what keeps you from
> working. a few delayed integrations certainly don't sound like a
> particularly convincing reason ...

I can't get the CI to tell me if there's anything wrong. Even if I stage now 
(which I have done), it will run on Monday morning, at a time at which I'll be 
busy packing. I'll get home in Portland on Tuesday evening UTC, close to 
midnight Wednesday. That'll be my first chance to see if any of my integrations 
failed due to CI issues.

So let me summarise: 
- the new way is actually good
- a minor downtime is acceptable
- provided that the CI is set up ahead of time (this time it was just learning 
  the ropes)
- people should send you a list of changes to retarget before the branching, 
  so if they haven't integrated before the branching, people can continue 
  working

The problems this time around were:
1) unexpected change in procedure compared to last times around
  => solution: no need, since we'll know it for the next times
2) CI was not ready in time for the new branch
  => solution: I don't know, QA team please chime in with a suggestion

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