Open Stack

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.

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.

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