Canonical Voices

What Björn Tillenius talks about

Posts tagged with '{'term': u'launchpad'}'

To start with, I think drive-by fixes are great. If you see that
something is wrong when fixing something else, it can be a good idea to
fix it right away, since otherwise you probably won’t do it.

However, even when doing drive-by fixes, I still think that each
landed branch should focus on one thing only. As soon as you start to
group unrelated things together, you make more work for others. It might
be easier for you, but think about all the people that are going to look
at your changes. Please, don’t be lazy! It doesn’t take much work to
extract the drive-by fix into a separate branch, and most importantly to
land it separately. If you do find that it’s too time-consuming to do this, let’s talk, and see what is taking time. There should be something we can do to make it easier.

There’s no such thing as a risk-free drive-by fix. There’s always the
potential of something going wrong (even if the application is
well-tested). When something goes wrong, someone needs to go back and
look at what was done. Now, if you land the drive-by fix together with
unrelated (or even related) changes, you basically hide it. By reducing
your workload slightly, you create much more work for someone else.

For example, on Friday I saw that we had some problems with scripts in
Launchpad. They were trying to write to a mail directory, to which they
didn’t have access. That was odd, since scripts have always talked to
the SMTP servers directly, and didn’t use the queued mailer that needed
write access to that directory. Looking through the recent commit logs
didn’t reveal anything. Luckily enough, William Grant pointed out that
r9205 of db-devel
contained a change to sendmail.py, which probably was the cause of the
problems. This turned out to be correct, but it was still pretty much
impossible to see why that change was made. I decided that the best thing
to do was to revert the change, but I wasn’t sure exactly what to
revert. That diff of that revision is more than 4000 lines, and more
than 70 files were changed. So how can I know which other files were
change to accommodate the change in sendmail.py. I tried looking at
the commit logs, but that didn’t reveal much. The only thing I could do
was to revert the change in sendmail.py and send it off to ec2,
waiting three hours to see if anything broke.

So, I plead again, if you do drive-by fixes (and you should), please
spend a few minutes extra, to extract the fix into a separate branch,
and land it separately!

I’ve been working on a new release/merge workflow for Launchpad.
I’ve written it from the developers’ point of view, but I’d love some
comments from users of launchpad.net, so let me try to explain how you, as
users, would be affected by this change.

The proposal is that we would decouple our feature development cycles
from our release cycles. We would more or less get rid of our releases,
and push features to our users when they are ready to be used. Every
feature would first go to edge.launchpad.net, and when it’s considered
good enough, it will get pushed to launchpad.net for everyone to use.
Bug fixes would also go to edge.launchpad.net first, and pushed to
launchpad.net when they are confirmed to work. Sadly, Launchpad will still go down once a month for updating DB and other regular maintenance, just like before. The amount (and frequency) of downtime would stay the same as before.

There are users who are in our beta team and use edge.launchpad.net
all the time, and those who want a more stable Launchpad, and use
launchpad.net.

Users of launchpad.net

Those who aren’t in the beta team would get bug fixes sooner than with
the current workflow. Instead of having to wait for the end of the
release cycle, they will get it as soon as the fix has been confirmed to
work on edge.launchpad.net. The same is true for features, kind of.
These users would have to wait a bit longer than today, since today we
push even unfinished features to launchpad.net users at the end of the
release cycle. With the new workflow, these users would have to wait for
the feature to be considered complete, but in return these user should get
a better experience when seeing the feature for the first time.

One potential source of problem is that even though fixes and features
get tested on edge.launchpad.net, before going to launchpad.net,
with each update there is the potential of some other issue being introduced. For example, fixing a layout bug on one page, might make another page look different.
With the current workflow this happens only once a month, instead of a
few times every month with the new workflow. That said, even today we
update launchpad.net multiple times every month, to fix more serious issues.

Users of edge.launchpad.net

If you are in the beta team, and use edge.launchpad.net on a regular
basis, it won’t be that different from how it works today. Just like today, you
would be exposed to features that are under development. What would
change is that we will try to do a better job at telling you which
features that are on edge.launchpad.net only. This way you will have a
better chance at actually helping us test and use the features, and
tell us about any problems, so that we can fix it right away. This
should make you more aware of new features that are being added to Launchpad, and provide a better opportunity for you to make it better.

One potential source of problem here is that developers will know that
their work won’t end up on launchpad.net, before they say it’s ready,
so they push more rough features to edge.launchpad.net. Thus it could be
a more rockier ride than today. But of course, our developers care a lot
about their users, so they won’t land their work, unless it’s really good! :-)

Conclusion

My hope is that this will provide a better and stable experience for users of launchpad.net, and provide users of edge.launchpad.net a better opportunity to help us making new features rock! But I’m interested to hear what you, the actual users, think about this.

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.