I made the transition from the Bugs team lead to the Launchpad Technical Architect quite a
while ago. While the first time was spent mainly on satisfying my
coding desires, it’s time to define what I’m going to spend my time as
technical architect! My road map that shows the high level things that
I’ll be focusing on is available here:
I’ll also be writing blog posts (and sending mails to the launchpad-dev
mailing list of course) regularly to keep people updated with my
progress and findings. My blog is at http://tillenius.me/ and I tag all
posts related to Launchpad with launchpad.
I’m currently working on decoupling our feature development cycles with
our release cycles, which I do mainly, because I think it’s important, not because it’s part of the technical architect’s responsibility.
But in parallel with that my next task is to set up a team that can help
me doing a good job. I’ll expand more about the team in another post,
but in short it will consist of members from each sub-team in Launchpad.
It will act as a forum to discuss what needs my attention, and they will
also help me figuring out solutions to problems, and help me implement
the solutions.
One of the first major tasks will be to come up with a testing strategy.
Currently when we write tests we don’t think that much about it.
Everyone have their preferences, and we have a wide variety of testing
styles, making it hard to find which code paths are exercised by which
tests, and how good test coverage we have. This leads to us sometimes having
bad test coverage, and some times having too much test
coverage, i.e. we have redundant tests that make the test suite slower.
Coming up with guidelines on how to write tests, which kind of tests to
write, where to place them, etc., is the first step. But we also need to
figure out how to make our test suite faster, what kind of documentation to
provide, and so on.
In addition to the tasks on the roadmap, I also have a number of things I do on a regular basis. This includes reviewing database patches for API consistency, help teams design features from a technical point of view, keep my eyes open for areas in the code that need refactoring and clean-up.
We’ve used Windmill in our Launchpad buildbots for a while now, and it’s actually
worked out quite well. I was afraid that we would have a lot of fallout,
since in the beginning Windmill was fragile and caused a lot of
intermittent test failure. However, so far I’d said that we’ve had very
little problems. There was one intermittent failure, but it was known
from the beginning that it would fail eventually. Apart from that we’ve
had only one major issue, and that’s that something is using 100% CPU
when our combined Javascript file is bigger than 512 000 bytes. This
stopped people from landing Javascript additions for a while, and we
still haven’t resolved this issue, apart from making the file smaller.
There are some things that would be nice to improve with regards to
Windmill. The most important thing is to make sure that launchpad.js can
be bigger than 512 000 bytes:
It would also be nice to make the test output nicer. At the moment
Windmill logs quite a lot to stderr, making it look like the test
failed, even though it didn’t. We don’t want Windmill to log anything
really, unless it’s a critical failure:
I was going to say that we also have some problems related to logging in
(because we look at a possibly stale page to decide whether the user is
logged in), but it seems like Salgado already fixed it!
It would also be nice to investigate whether the problem with asserting
a node directly after waiting for it sometimes fails. We had problems
like that before; code was waiting for an element, and when using
assertNode directly after the wait, the node still didn’t exist. I
haven’t seen any test fail like that lately, so it might have been fixed somehow:
There are some other things I could think of that would be nice to have.
I haven’t found any bugs filed for them, but I’ll list them here.
- Don’t run the whole test suite under xvfb-run. It’d be better to start xvfb only for the Windmill tests.
- Use xvfb by default for Windmill tests. When running the Windmill tests it’s quite annoying to have Firefox pop up now and then. It’d be better to run them headless by default.
- Switches for making debugging easier. Currently we shut down Firefox after running the Windmill tests. It should be possible to have Firefox remain running after the test has finished running, so that you can manually poke around if you want to. If we use xvfb by default, we also need a switch for not using it.
