• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

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

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:

• 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.

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)?