Hello.<div><br></div><div>I'm probably prying out of my area of expertise, but anyway.</div><div>I think that to prevent confusion when it comes to global parts of Nova, this project should be separated to couple of subprojects, including one for the core and e.g. one for every hypervisor supported. When someone wants to create some great new feature in Core, one is responsible to make it work with "Tier-1" hypervisor(s). After that feature can be committed to core's and hypervisor's trunks. Then we have other projects' breakage that should be solved by responsible person in every project.</div>
<div>I think, such division should ease both development and usage of Nova. There can be for example python-nova-libvitrt package that will install only necessary parts of Nova and directly require python-libvirt. Among other things this will prevent late imports that can confuse newbies and test writers.</div>
<div><br></div><div>I hope I could make my point as clear as it can be.</div><div><br><div>Kind regards, Yuriy.</div><br>
<br><br><div class="gmail_quote">On Thu, Aug 4, 2011 at 13:17, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Ewan Mellor wrote:<br>
> I think, having read through everything that Vish said, and everything<br>
> you guys have said, the only problem we have here is one of communication.<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> I’m sure that Trey didn’t _/want/_ to skip these tests, and I know that<br>
> Vish accepted the patch knowing the downsides. He had to trade off the<br>
> time taken to fix everything perfectly, versus the further remerging /<br>
> rebasing that would have been necessary if the patch got stalled for any<br>
> longer. I agree with Soren that this was not a desirable thing, and I<br>
> think everyone else would too, but Vish made that decision in full sight<br>
> of the facts, and I’m happy to support him in that, even though it’s my<br>
> team that’s taken the hit in this case.<br>
<br>
</div>We shouldn't have accepted disabling tests, at the very least not<br>
without a clear plan to fix them, which includes creating bugs and<br>
targeting them against milestones (so that they appear in release<br>
management radar), and reviewing progress weekly at the team meeting.<br>
<br>
> [...]<br>
<div class="im">> I don’t know if either of them will like this idea, but maybe we could<br>
> make it Vish’s problem or Theirry’s problem to think about whether the<br>
> right communication is happening. By that I mean, when the blueprint is<br>
> reviewed / accepted for a release, either the PTL or the release manager<br>
> could take the time to think about whether anyone else should be on the<br>
> blueprint for notification or involvement.<br>
<br>
</div>It can be difficult to assess in advance when such coordination is<br>
needed... but I'd say the PTL should definitely be involved to<br>
facilitate complex collaboration when required to push a feature... and<br>
the release manager should definitely be in the loop to make sure<br>
everything is fixed in time.<br>
<br>
The main issue here is that this should have raised all kinds of alarms<br>
and it didn't -- the need for fixing the tests was inadvertently<br>
discovered a couple days before milestone release.<br>
<font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div>