openstack team mailing list archive

[Yuriy Taraday <yorik.sar@xxxxxxxxx>]

Hello.

I'm probably prying out of my area of expertise, but anyway.
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.
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.

I hope I could make my point as clear as it can be.

Kind regards, Yuriy.



On Thu, Aug 4, 2011 at 13:17, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:

> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>