launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, Nov 18, 2010 at 1:39 AM, Ian Booth <ian.m.booth@xxxxxxxxx> wrote:
>>
>> The candidates I have already are:
>>  - fixing a bunch of baseline issues - like: overuse of interfaces,
>> scripts not establishing participations, sqlbase migration. Time
>> consuming, tricky things that need some attention to detail, but which
>> when done will significantly simplify much of our code base.
>
> As Jelmer said, these sorts of things are perhaps viewed as tech debt
> issues. So long as there is collective agreement on how and what to do
> to address them, I think each team should be able to do their bit so to
> speak, as long as we all are pulling in the same direction.

On this point - they aren't in any teams roadmap, and they are, as I
say, tricky. Tricky things require dedicated hacking time to absorb
the problem, internalise, model and come up with solutions. I predict
that until someone puts aside, oh, a week, we won't get any traction
on scripts with participations.

>> For now, I'm going to stay mum on which option I think has the best
>> cost/reward tradeoff for us at the moment, and I'm sure I've missed a
>> brilliant idea that will obsolete all of these :)
>>
>> I await your suggestions!
>
> This isn't of huge importance compared to the other things already
> covered, but I'd love Launchpad to play nicer with Postgres in that
> several instances of Launchpad as well as other apps could co-exist on
> top of the one Postgres instance. This could be done by placing the
> tables etc for each Launchpad instance into a different Postgres schema.
> Thus "make schema" would trash that particular Launchpad's schema and
> leave everything else hosted inside the Postgres instance alone. One
> benefit - it would be much more convenient to have develop on branches
> derived from devel and db-devel and switch between them without losing
> data. This is more of a development task rather than a TA thing but I'd
> thought I mention it anyway.

See my db-fixtures branch :). It doesn't define a unique test fixture
template, but that would be easy to add once its landed.

-Rob