Moving udd to django

[Vincent Ladeuil]

>>>>> James Westby <jw+debian at jameswestby.net> writes:

    > On Tue, 13 Dec 2011 09:11:36 +0100, Vincent Ladeuil <vila+udd at canonical.com> wrote:
    >> >   3. It would also allow for starting to move udd to an SOA, or at least
    >> >   make it easier.
    >> 
    >> Not a concern for udd so far.

    > Actually I'd like to turn add_import_jobs in to a separate service, as
    > it could be shared between udd and pkgme, and other services that people
    > want to build, reducing load on Launchpad. That would be much easier if
    > udd was in django (or twisted, or go, or ...)

True, but I'm not saying your plan is *bad* for udd, quite the
contrary. And yes, sharing some service to query launchpad sounds also
like a good idea (I think I mention adding pkgme to mass_import and
that's one of the points I had in mind). But this can achieved only by
either running both pkgme and udd on the same host or add yet another
layer to access the db remotely. In both cases, what I'm saying is that
udd has already higher priorities.

    >> >   4. It would be nice to have a query builder, rather than all the
    >> >   hand-written sql.
    >> 
    >> Not a big problem for udd so far.

    > Indeed, but I consider it technical debt, and it makes the code harder
    > to read and change.

Again, I agree with that, but the technical debt., IMHO, is on the test
front.

I think it will be far easier to write the tests during the independent
rewrite than adding them to the actual one (test before is always far
easier than test after).

My gut feeling is that you'll get a far better test suite covering the
same features if you're not bound by the constraint to not break udd in
production.

    > I would be worried about the risks involved with changing
    > production udd in such a large way at once. The steps I outlined
    > here would involve targeted production changes that should be much
    > easier to debug.

But if you follow these steps during your rewrite, nothing forbids
following them when deploying once we know you've fully debugged them
right ?

    >> Both projects will benefit from this separation: 
    >> 
    >> - pkgme can go ahead without caring for udd needs, as long as the actual
    >> code base evolve by separating old features from the new ones with a
    >> reasonable effort to make the new ones easier to integrate.

    > I don't think that's true. It's not like we don't care about udd,
    > and if we make changes without regard for it

Why would you do that ?

    Vincent