Open Stack

>From my experience, directly adding incubated projects to the main Horizon codebase prior to graduation has been fraught with peril. That said, the closer they can be together prior to the graduation merge, the better.

I like the idea of these types of projects being under the OpenStack Dashboard Program umbrella. Ideally I think it would be a jointly-managed resource in Gerrit. The Horizon Core folks would have +2 power, but the Tuskar core folks would also have +2 power. (I'm 90% certain that can be done in the Gerrit admin...)

That way development speed isn't bottlenecked by Horizon Core, but there's a closer tie-in with the people who may ultimately be maintaining it. It becomes easier to keep track of, and can be more easily guided in the right directions. With a little work incubated dashboard components like this could even be made to be a non-gating part of the testing infrastructure to indicate when things change or break.

Adding developers to Horizon Core just for the purpose of reviewing an incubated umbrella project is not the right way to do things at all.  If my proposal of two separate groups having the +2 power in Gerrit isn't technically feasible then a new group should be created for management of umbrella projects.

All the best,

     - Gabriel

> -----Original Message-----
> From: Julie Pichon [mailto:jpichon at redhat.com]
> Sent: Wednesday, December 18, 2013 4:50 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and
> Tuskar-UI codebase merge
> 
> "Jaromir Coufal" <jcoufal at redhat.com> wrote:
> > Hi All,
> >
> > After yesterday's weekly meeting it seems that majority of us is
> > leaning towards this approach (codebase merge). However there are few
> > concerns regarding speed of development and resources especially for
> reviews.
> > With this e-mail, I'd like to kick off discussion about how we might
> > assure to get enough people so that we can fulfill Horizon as well as
> > Tuskar-UI goals.
> 
> It seems to me the opinions were still divided in the meeting, and this is why
> we are continuing the discussion. Personally I'm more favourable to the initial
> proposal, of moving the tuskar-ui repository under the Horizon program.
> Existing Horizon cores add it to their Watched Changes under Gerrit, just like
> for Horizon and django_openstack_auth now, and get familiar with the
> project during its development. Tuskar-ui cores can move their discussions to
> the #openstack-horizon channel and that's another way that we all become
> part of the same horizon community, and another chance for the horizon
> folks to understand what's important to Tuskar.
> 
> There's a number of exceptions that are being requested, that make me
> think now is not the right time to just merge the code into the main horizon
> codebase. A few that have come up during the IRC meeting:
> 
>  - Request for more attention due to the need to move very fast
>  - (Possibly) Request for an exception to the same company approval
>    rule
>  - Request to be able to check in broken stuff at times
> 
> In my mind these requirements come from being an incubated project with
> different priorities, which is fine but make the project not suitable for the
> main horizon codebase yet.
> 
> I think it makes more sense to merge once the project is integrated, like
> we've done so far. Another discussion on list ([1]) makes it clear that there's
> no promise an incubated project will become integrated, and that it can be
> dropped from incubation. IMHO that's another argument for waiting for a
> project to be integrated before merging it. This doesn't mean it doesn't get
> any attention from the existing Horizon team.
> 
> I think extending this rule to all - moving dashboard components from
> incubated projects under the Horizon program - would be more reasonable
> and easier to scale, than the proposed alternative.
> 
> > With respect to the e-mail which was sent Dec 17 (quoted below), I
> > think all of what was written applies, we just need to clarify couple
> > more details. And I hope we can get to consensus by the end of this
> > week so that we can make things happen.
> >
> >
> > *Blueprints:*
> > Currently there is couple of already existing blueprints for Tuskar-UI
> > and there will appear more based on wireframes around deployment
> setup
> > (which are not finished yet).
> >
> > https://blueprints.launchpad.net/tuskar-ui
> >
> > We want to make sure, that Horizoners are fine with these blueprints
> > being merged with Horizon ones, keeping their priorities and that
> > there will appear couple more in time.
> >
> >
> > *Cores:*
> > To make sure that we have enough people to get the code in and also to
> > help Horizoners to free load of reviews on their side, we propose to
> > merge our core team (plus rdopieralski). All of them contributes to
> > Horizon so they know the code well.
> >
> > People we are talking about:
> > - jomara
> > - jtomasek
> > - lsmola
> > - rdopieralski
> > - tzumainn
> >
> > - (jcoufal) - At the moment I am in the core team but not doing
> > reviews that often. From time to time I check implementation if it
> > matches vision. With speeding up development, I will try to do more
> > but not that often as above mentioned guys. My role there is more
> > about helping to triage bugs and blueprints based on wireframes,
> > project goals and direction. I am completely OK with not being
> > included in core team after merger, I just want to ask if I can keep
> > being able to help with blueprints and bugs triaging.
> >
> > Of course, everybody in core team needs to keep on track. We can
> > evaluate the list in time and if anybody is not doing reviews
> > properly, they should be removed from the list.
> >
> > So the question here is, if Horizoners are OK with above listed guys
> > being merged to horizon-core team?
> >
> >
> > *Reviews:*
> > Even after merger we would love to keep cross-company reviews culture.
> > And here are the main concerns I believe. I envision that the code
> > will be developed really fast and will need attention for reviews. If
> > we can't get code in, in reasonable time, Tuskar UI goals for Icehouse
> > are jeopardized. So we should try to at least get to consensus about
> > notion of future cores cooperation, so we feel that it can work well.
> >
> > My proposal:
> > I think we are able to keep cross-company reviews approach. As was
> > said there are about 6 non-redhat cores in Horizon. What can we do to
> > ease the load for them?
> >
> > * Tuskar UI cores will help with reviews in Horizon (this will
> > decrease the number of needed reviews in Horizon in general)
> > * Tuskar UI cores will review the Tuskar UI code, their main
> > responsibility will be that the code works well from functional and
> > TripleO point of view.
> > * Horizon core reviewer doesn't have to assure that the code works
> > well from TripleO point of view (furthermore it might be hard for them
> > to get the setup with Tuskar UI working, at least from the beginning).
> > * Horizon core reviewer can just keep eye on whatever code is trying
> > to get into Horizon's codebase, that it makes sense for Horizon's
> > standards. So he/she just blesses that this is the right way to do it
> > in Horizon.
> 
> This doesn't seem like the right approach to me, just adding people to
> Horizon core so that the current core can focus their attention elsewhere (on
> Tuskar-ui). It seems like we're expecting the new cores to learn on the go the
> kind of things Horizon folks look for in reviews usually, opposite to the way
> people normally get invited to join core after a while.
> 
> I'm glad to see how keen tuskar-ui is to have a cross-company culture and
> reviews, but I'm not sure either if putting pressure on the current Horizon
> cores from other companies to prioritise Tuskar-ui is the right/best way to
> achieve it...
> 
> I still think Tuskar-ui is a great fit for the Horizon program, and look forward to
> becoming more familiar with it. In my opinion though, as a rule it's better to
> merge/support a project in the main horizon codebase once it's integrated.
> 
> Julie
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2013-
> December/022546.html
> 
> > In time Horizon core reviewers will get more familiar with Tuskar UI
> > and will be able to evaluate also other areas. But we don't want to
> > burden you guys with completely new complex area asking for approvals
> there.
> >
> > I was also asking for fallback plan. If we merge and the speed of
> > development will be slowed by reviews (that it won't work that smooth
> > as we expected), if we can ask for exception for cross-company reviews
> > in Tuskar-UI (until the end of Icehouse cycle). I hope it won't be big
> > problem since it was already suggested and David was also open to this
> > from the beginning. However I don't think this should be primary
> > approach, just fallback plan.
> >
> > Any other ideas? Thoughts?
> >
> > Thanks everyone
> > -- Jarda
> >
> >
> > PS: One small comment inline:
> >
> > On 2013/17/12 11:04, Ladislav Smola wrote:
> > > Horizoners,
> > >
> > > As an alternative merge option, we could merge directly to Horizon
> > > code base. After some conversation, we have realized that it is
> > > possible to mix codebase of incubated and integrated projects, as Trove
> showed us.
> > > Contrary to what was said in the last meeting, we do not require any
> > > special treatment for the infrastructure tab and we will continue
> > > the development of the infrastructure tab with the same rules as the
> > > rest of the Horizon. Especially, we want to keep culture of cross
> > > company reviewers, so that we make sure that TripleO/Tuskar UI is
> > > not only in hands of one company. It is important to mention that
> > > there will be more code to keep eyes on but we believe that us
> > > helping more with reviews in Horizon will give more time for reviews in
> TripleO/Tuskar UI.
> > >
> > > This is proposed Roadmap:
> > >
> > > 1. Before meeting 16.12.2013, send email about the merge.
> > > 2. Immediate steps after the meeting (days and weeks)
> > > - Merge of the Tuskar-UI core team to Horizon core team. Namely:
> > > jtomasek, lsmola, jomara, tzumainn (a point of discussion)
> > I would like to propose also rdopieralski. He is not part of current
> > Tuskar-UI core team, because he joined the team just a bit later after
> > merger, but he knows almost each piece of code in Tuskar UI, he has
> > great knowledge about the code in Horizon and he is helping a lot to
> > move the development forward.
> >
> > > - Tuskar will add a third panel, named "infrastructure".
> > > - Tuskar will be disabled by default in Horizon.
> > > - Break tuskar-ui in smaller pieces, submit them individually as
> > > patches directly for horizon.
> > > 3. Long-term steps after the meeting (weeks and months)
> > > - Synchronize coding style and policies.
> > > - Transfer blueprints and bugs to horizon launchpad with 'tuskar-' prefix.
> > > - Continue development under in Horizon codebase. Infrastructure tab
> > > will have some tabs implemented with mock data, until the underlying
> > > libraries are finished (Tuskar is depending on several apis, like
> > > nova, heat, triple-o, ironic.). It will get to stable state in I3
> > > (we need to develop in parralel with API's to meet the I3 deadline)
> > > - Transfer Documentation.
> > >
> > > The benefits of this was already pointed out by mrunge.
> > >
> > > We have a detailed plan of features for I2 and I3, put together by
> > > the tripleo community, those will be captured as blueprints and
> > > presented on Horizon meetings.
> > >
> > > If you have any questions, please ask!
> > >
> > > Thanks,
> > > Tuskar UI team
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev