Open Stack

Ewan Mellor wrote:
> I think, having read through everything that Vish said, and everything
> you guys have said, the only problem we have here is one of communication.

Yes.

> I’m sure that Trey didn’t _/want/_ to skip these tests, and I know that
> Vish accepted the patch knowing the downsides.  He had to trade off the
> time taken to fix everything perfectly, versus the further remerging /
> rebasing that would have been necessary if the patch got stalled for any
> longer.  I agree with Soren that this was not a desirable thing, and I
> think everyone else would too, but Vish made that decision in full sight
> of the facts, and I’m happy to support him in that, even though it’s my
> team that’s taken the hit in this case.

We shouldn't have accepted disabling tests, at the very least not
without a clear plan to fix them, which includes creating bugs and
targeting them against milestones (so that they appear in release
management radar), and reviewing progress weekly at the team meeting.

> [...]
> I don’t know if either of them will like this idea, but maybe we could
> make it Vish’s problem or Theirry’s problem to think about whether the
> right communication is happening.  By that I mean, when the blueprint is
> reviewed / accepted for a release, either the PTL or the release manager
> could take the time to think about whether anyone else should be on the
> blueprint for notification or involvement.

It can be difficult to assess in advance when such coordination is
needed... but I'd say the PTL should definitely be involved to
facilitate complex collaboration when required to push a feature... and
the release manager should definitely be in the loop to make sure
everything is fixed in time.

The main issue here is that this should have raised all kinds of alarms
and it didn't -- the need for fixing the tests was inadvertently
discovered a couple days before milestone release.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack