Moving udd to django

[James Westby]

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

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

>     > 1) Install python-django in production
>     >    - So that it is there when it is needed.
> 
> This should be cheap. On the other hand, if newer versions are needed
> (which would be known during the dev/test phase) this will also be
> useless.

Coding to django 1.1 (lucid) is not too restrictive. IS can also run
django 1.3 if absolutely required.

>     > What do you think? Is this worth doing?
> 
> Frankly ? This certainly sounds like a very good plan.
> 
> I also think udd doesn't need any of that in the short term.
> 
> Now, if you do it for pkgme, we will certainly be interested in
> cannibalizing part or all of it.
> 
> In the mean time, the less disruptive changes we do to udd, the more we
> can focus on the import failures which is where the paint points are.

I do think dealing with import failures is good, but I'm not sure the
approach you advocate is the right one.

> What I mean is that forcing the use of the same code base for two
> projects with different goals sounds like a sure way to trigger failures
> for the other project without benefits for the project needing the new
> features. We've already encountered such issues at a small scale and
> until the test suite become rock-solid, I fail to see while we won't
> encounter new issues.
> 
> I.e.: It sounds easier to separate common parts from specific parts in
> the actual udd code base while starting a *new* project than doing so in
> the udd code base that is already in production. Once those parts are
> clearly separated, the package importer can look at integrating the new
> and well-separated udd.

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.

> 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 then it's likely that either lots
of changes will be required to support udd again, or udd will never used
the new codebase.

> - udd won't have to integrate incremental steps that bring no added
>   value but still cost deployment/debugging time or do so *only* when a
>   tangible benefit emerge *and* addresses issues.

If you believe this then we can go away and ignore udd, but I fear it
will be more work and more risk in the end.

Thanks,

James