Confirmed users
2,492
edits
Electrolysis/Firefox: Difference between revisions
Jump to navigation
Jump to search
→Risks
(→Risks) |
|||
| Line 47: | Line 47: | ||
==Risks== | ==Risks== | ||
There are a number of problem or risk areas we have identified that will have to be tackled early on in the project. Some we understand how to mitigate, others | There are a number of problem or risk areas we have identified that will have to be tackled early on in the project. Some we understand how to help mitigate, others require some experiments to be run in order to give us more visibility. | ||
*1. What are all the places that chrome touches content? | *1. What are all the places that chrome touches content? | ||
** We really don't have our head wrapped around this. | ** We really don't have our head wrapped around this. | ||
** We can instrument the code to tease out some of this information and the patterns. | ** We can instrument the code to tease out some of this information and the patterns. | ||
** There are differing perspectives on the value of instrumentation for this purpose but there is agreement that providing us with more data is positive. | |||
** We need to engage people familiar with this code to participate in early discussions and help tease out the highly interactive areas. | ** We need to engage people familiar with this code to participate in early discussions and help tease out the highly interactive areas. | ||
| Line 69: | Line 70: | ||
*4. Goals, metrics and measurements | *4. Goals, metrics and measurements | ||
** We need clear goals, metrics and measurements at the beginning of the project. | ** We need clear goals, metrics and measurements at the beginning of the project. | ||
** It | ** It needs to clear what we are aiming for and going to measure. | ||
** We need to start measure early in the project so we can identify problem areas sooner. | |||
*5. What scale of architectural change is required in certain areas? | *5. What scale of architectural change is required in certain areas? | ||
| Line 79: | Line 81: | ||
** Find the areas that don't have test coverage. | ** Find the areas that don't have test coverage. | ||
*7. | *7. Temptation to rearchitect everything | ||
** To help mitigate this we will require discipline and clear decisions. | |||
** We need to figure out all the pieces that we really need to have. | |||
** Some will have to be completely reworked, others less so. | |||
** Evaluating these decisions by making back to the larger project goals is key. | |||
*8. Current state of module ownership | |||
**Some areas that will be changing are in old code with no clear owner or expert. | |||
**Need to identify these up front. | |||
*9. Impact to other apps | |||
** Lower priority risk. | |||
** It's true that there are other apps that might be affected SeaMonkey, Thunderbird. | |||
** Communicating to them is a bit like outreach. | |||
** We should remember to make as much of our work as visible as possible so they understand if they are impacted by any core changes. | |||
10. Further changes to Platform | |||
** There is likely to be some changes needed for Firefox that we did not identify as part of the Mobile project. | |||
** We don't anticipate this to be a high risk area but wanted to note it. | |||
==Implementation== | ==Implementation== | ||