launchpad-dev team mailing list archive

[Ian Booth <ian.m.booth@xxxxxxxxx>]

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

>  - test suite parallelisation: parallelisation initially, then
> parallelisation in our CI/landing robot

Like everyone else, +1 on this. The job has been started, is well
progressed, and the benefit is large. Let's keep the momentum and get it
done.

>  - data mapping layer: Build and deploy across the whole code base a
> dedicated persistence layer.
>    This would be a choke point through which all database access goes,
> would include the group based idiom I've been rabbiting on about, and
> to be successful would define an iron-clad contract which we can
> confidently replace with a testable test double. I'd be looking to
> form a working-group for this - a group of interested folk seconded
> from their regular team to work with me on developing and deploying
> this project wide.

I think my view on this is fairly well established. I'm interested in
helping :-)

>  - faster/easier stock page creation: Suggested by Gary, this would
> aim to massively reduce the overhead in the non-ajax form development,
> so that we can focus on ajax form development. For instance, perhaps
> we'd get rid of generated forms and use node.js to render pages server
> side when working with a javascriptless browser.
> 

I'm also +1 with Jonathon on ditching non-ajax development. IMHO,
Launchpad's UI needs to be modernised to fit with what today's users
expect from web apps. #1 for me would be adding a whole lot more in-page
editing via smart popups (ie avoiding the need to navigate away from the
current page and back again just to add some data relevant to the
current workflow). The popups we do have also need to be smarter eg with
the bug entry one, compared to what other systems like Atlassian's JIRA
offer, ours is pretty primitive. So in other words, let's focus our
limited resources on taking the product forward and embracing modern
technologies.

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