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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
