launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Nov 3, 2010 at 2:58 AM, Marc Tardif <marc.tardif@xxxxxxxxxxxxx> wrote:
> For example, I have a recurring dream
> of extracting the Librarian from Launchpad as a standalone project.

I realise I missed answering this. The librarian depends on the
Launchpad schema, and the Launchpad schema depends on this.

I think to accept a patch that splits out something which depends on
the schema and is part of the definition of the schema we need to
require that it not add a maintenance burden. Some specific
requirements would be that:
 - make schema stays deterministic
 - database patches can still be trivially located, reported, sorted and applied
 - dependencies must be one-way (Launchpads main tree may depend on a
dependency, but not vice versa).
 - cost of making an atomic-like change to schema and layers above it
must not increase
 - testing (and test maintenance) must also improve or at worst remain the same.

Offhand, for the librarian, you'll need to start by moving all the
schema management and generation code out of LP and solving the
problems that will occur when you do that - and by solving, I mean
'must be better than it is now' - and its quite polished where it is
:).

I see very little benefit (and many costs) in physically moving things
out of tree that are part of Launchpad and not generic. The Librarian
is arguably generic in that you can make a stubby self-contained code
graph for it, but its not designed as a truly generic component - and
in fact, in terms of 'blob storage components' there are many
standalone competitors these days:  I think we'd get more from
remodelling to use an S3-alike with built in N-node storage, HA, and
HTTP uploads than from splitting the librarian out. We could just
delete the librarian at that point.

-Rob