> > 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
