Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge
"Jaromir Coufal" 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 w
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge
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
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge
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) - 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 Just one small note here: TripleO/Tuskar UI's goal is to deliver working slick installer for Icehouse. Which means lot of work and lot of code will need to get in as fast as possible. In other words we need to develop rapidly. I think what we will need to discuss on today's meeting is the way how reviews in Horizon might look like after the merger. What things should get priority, how to assure cross-company culture, etc. I believe there won't be big issues, we just need to clarify all that stuff and make sure that we can fulfill all UI goals - Horizon's and TripleO/Tuskar's. Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge
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) - 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
