launchpad development|
Size: 2201
Comment:
|
Size: 3170
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 37: | Line 37: |
| lp:~salgado/launchpad/project-to-bugs-adapter has an adapter for IProduct to IBugTarget (diff can be seen at http://paste.ubuntu.com/456511/), which is part of what we'll do to make the registry not have hard dependencies on any other apps. Here are some issues I encountered so far: | == Making the registry not depend on other apps == |
| Line 39: | Line 39: |
| * Should we have a single adapter per facet or multiple? * IBugTarget now inherits from ICanBeBugTarget, and IProduct inherits from the latter. I've done that so that we don't have to duplicate the browser:page declarations. * Some app-specific things are edited through the project's main +edit page (e.g. bug_reporting_guidelines, official_* and translation_focus, just to name a few). Although editing these doesn't seem to depend on any app-specific bits, it might do for others. |
Currently, every application depends on the registry, which in turn depends on every other application. That makes it impossible to break Launchpad into separate applications, so we'll start by making sure the registry does not have hard dependencies on any other application. For example, the Product model class implements IBugTarget, but the code that does that uses stuff from lp.bugs. We will move that code into an adapter for IProduct to IBugTarget so that Product no longer depends on lp.bugs. lp:~salgado/launchpad/project-to-bugs-adapter has an adapter for IProduct to IBugTarget (diff can be seen at http://paste.ubuntu.com/456511/). Here are some issues/questions I have so far: 1. IProduct no longer extends IBugTarget, so the pages registered for IBugTarget won't be available for IProducts. (the diff above has a long comment with a few possible solutions) To work around that, I've created ICanBeBugTarget, moved all IBugTarget pages to it and made both IBugTarget and IProduct inherit from it. That way the pages are available for classes implementing either IBugTarget or ICanBeBugTarget. 1. I created an adapter specific to the IBugTarget interface, but instead we could have a single adapter that provides all the bugs-related interfaces currently implemented by Product (e.g. IProductBugs). The only advantage I see is if we want to do the automatic adaptation solution for item 1 above. 1. Some app-specific things are edited through the project's main +edit page (e.g. bug_reporting_guidelines, official_* and translation_focus, just to name a few). Although editing these doesn't seem to depend on any app-specific bits, it might do for others. |
The APPocalypse
The apocalypse split the LP codebase in to app packages. We wish to continue this effort and clean up some remaining parts where the split isn't quite as clean as it should be.
We would then like to build on this in order to actually split the codebase in to separate branches, with the following gains:
- A subset of tests will cover each app, reducing the test cycle.
- Cleaner code with less mixing of concerns.
- Ability to deploy Soyuz without the other apps.
What we are not doing:
- Splitting every app in to a standalone project that can run independent of everything else.
- Splitting the database.
The plan
We will aim to have several clearly defined layers:
- Foundations (possibly more like a set of libraries)
- Registry
- Soyuz
- Everything else
and attempt to only have each item in that list import from the one above.
Where one part can communicate with lower layers we will use soft dependencies, possibly built around a messaging system to allow them to co-operate.
Design
Implementation
Making the registry not depend on other apps
Currently, every application depends on the registry, which in turn depends on every other application. That makes it impossible to break Launchpad into separate applications, so we'll start by making sure the registry does not have hard dependencies on any other application.
For example, the Product model class implements IBugTarget, but the code that does that uses stuff from lp.bugs. We will move that code into an adapter for IProduct to IBugTarget so that Product no longer depends on lp.bugs.
lp:~salgado/launchpad/project-to-bugs-adapter has an adapter for IProduct to IBugTarget (diff can be seen at http://paste.ubuntu.com/456511/).
Here are some issues/questions I have so far:
- IProduct no longer extends IBugTarget, so the pages registered for IBugTarget won't be available for IProducts. (the diff above has a long comment with a few possible solutions)
- To work around that, I've created ICanBeBugTarget, moved all IBugTarget pages to it and made both IBugTarget and IProduct inherit from it. That way the pages are available for classes implementing either IBugTarget or ICanBeBugTarget.
- I created an adapter specific to the IBugTarget interface, but instead we could have a single adapter that provides all the bugs-related interfaces currently implemented by Product (e.g. IProductBugs). The only advantage I see is if we want to do the automatic adaptation solution for item 1 above.
- Some app-specific things are edited through the project's main +edit page (e.g. bug_reporting_guidelines, official_* and translation_focus, just to name a few). Although editing these doesn't seem to depend on any app-specific bits, it might do for others.
This is still a work in progress (lots of tests will probably fail), but it should help us identify possible pain points and see whether or not the whole idea is sane.
Unresolved issues
- Should we try to break the list of external dependencies (sourcedeps.conf and versions.cfg on a per-branch basis)?
