On Wed, Nov 3, 2010 at 2:58 AM, Marc Tardif <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
