According to Alex Chiang, being in Copenhagen just means “more work while being tired”. Well we’ve been hard at work, and so this will be coming soon…
Producing the best product in the least amount of time with the right amount of resources is all about efficiency. Here in Copenhagen I heard someone say today to be careful about making sure that nobody was blocked, that you helped anyone who needed help. The reason why this is important is that most projects will cascade a block downstream ending in a much larger delay than the original issue. For example, if you are waiting for the system architect to finish specifying an API, you’re blocked (as the implementer), but so is anyone who relies on your code or the QA team who tests it. There are many ways to solve these situations, mocks, fakes, etc. For example, when doing UI layout, I used to stick in a “FPO image” that was the right size so we could put the elements around it. On the command-line side, I used to just have my API return fake data until I could implement each feature. There are hundreds of other solutions. The goal was for me to implement the minimum so that everyone else could get started on their job and eliminate myself as the project bottleneck.
A great example of efficiency is what our hotel in Copenhagen has done with the elevators, with what I presume is an elevator scheduler. There is no up or down button, instead you enter what floor you want to go to. In theory, this allows the elevator to more efficiently schedule its trips. If there are people going to 10 different floors, say 3-7 and 21-25, it can send two elevators and the latter will be an express right to 21. With information gathered over days and months and data input about room usage, the elevators could stage themselves efficiently as well, up high in the mornings and in the lobby in the afternoon.
The elevators also only hold about six people, so instead of two large elevators, they use several smaller ones. If you have people going to a bunch of different floors they get split up into different elevators. After you enter your floor it tells you which elevator, you should wait in front of, this avoids you having to look around for which elevator to use. Then to improve efficiency more, it pre-selects your floor; when you enter the elevator your floor button has already been “pushed”. This is especially helpful in a crowded elevator in an international hotel when calling out “Seis, por favor” may not be understood by the person near the buttons.
Elevators were a major problem at the Oakland UDS where in the morning and evening there was large delays of up to 20 minutes to get on one. My roommate and I gave up on taking the elevator later in the week and ended up taking the stairs. When UDS starts up next week we’ll see how these keep up, but I’m hopeful they’ll work out.
So what does this have to do with code? Other than pondering how one might write an elevator scheduler and feed usage patterns back in for more efficient routing, the real point of this post was me just thinking about efficiency. When you’re working on a project, you should take a brief moment to consider who you are blocking and how you can solve that. More than likely, if you spend ten minutes to help someone who is stuck, the payoff for your project will be hours or more once the downstream effects are realized. You don’t want to be the elevators at the Oakland UDS, you want to be the elevators at the Copenhagen UDS.
EDIT: Since I’ve not done any research on this, does anyone know if the elevators really are using an intelligent scheduler? If you do, please comment.
A bug triager’s best friend is ubuntu-bug. Special per-package hooks in /usr/share/apport/package-hooks collect logs and config files that make bug triage and analysis much easier. The scripts also help to avoid the “Can you please post the … file?” back and forth that tends to waste time and many time ends up in an incomplete bug being marked expired. (As an aside when a bug submitter is asked for more info, the bug is marked Incomplete until it is updated, if it’s not updated in 60 days, it expires).
What does this have to do with lightdm? So tonight I shared my lightdm blog post with some people and Bryce Harrington suggested that I write an apport script for lightdm. I mentioned this brilliant plan to Robert Ancell and it turns out that lightdm has one already! Well my work is done! Except… The existing script wasn’t being packaged or installed, was collecting logs with the wrong (old) names, and didn’t collect the configs. All of that is fixed tonight with a MP I made, based on the code that Xorg’s apport script uses. Once it’s merged and released (probably not until R opens) we will have an apport script for lightdm. Once that happens, you can file a bug by simply typing:
There’s no apport script for any of the the greeters, at least not that I know of for unity-greeter or lightdm-gtk-greeter, but they’d need the same data. The only thing that this script doesn’t do is get a screencap/picture, that’s up to you guys.
I’ve been spending some time off and on cleaning and working on up the bugs in the lightdm project. Unfortunately someone who takes on this task, lightdm ends up with a lot of bugs that are not necessarily lightdm bugs and also lots of bugs with incomplete information. In a perfect world, everyone who was going to file a lightdm bug would read this, for now I’ll settle for spreading this information to anyone who reads my blog.
First a bit about the architecture. The job of the display manager (prior to lightdm) was to be a daemon, manage logins and sessions, run the display server, and provide a GUI to interact withe the user. Unfortunately since everyone has a favorite GUI technology, we ended up with a ton of different Display Managers (GDM, XDM, KDM, etc). The idea with lightdm was to separate the back-end work from the GUI. Everyone could re-use the back-end (lighdtm) and write their own GUI, also called a greeter, on top. So that’s where we are now, lightdm is a daemon process that manages everything, and a greeter, usually unity-greeter for Ubuntu or lightdm-gtk-greeter for Xubuntu deals with the user interaction. A PDF presentation on the architecture from the Desktop Summit is available here. Note: I assume Kubuntu uses the lightdm-qt-greeter but I’m not sure, if you know please comment here.
So why should you care about the architecture just to file a bug? The reason is that if you get your bug to the right package it will speed up the response. So here’s a real basic decision tree for you to follow when deciding what package to file against:
sudo tar -cvzf ~/lightdm_logs.tgz /var/log/lightdm/*
If you plan on filing a bug against lightdm or a greeter following these steps can really help us out and hopefully get you a resolution quicker. Thanks!
Ubuntu relies on “Masters of the Universe” or MOTUs to keep the universe and multiverse components of Ubuntu in good working order. Unlike main, which is officially supported by Canonical, universe and multiverse are community supported. So MOTUs are community members who spend their time adding, maintaining, and supporting these repos.
Even though I work for Canonical, I don’t have any special powers. If I want to upload a package to universe or multiverse, I need to talk to a MOTU or become one. In order to become one, I need to do the work and gain the experience required, just like anyone else in the community would. Since I came into this job without having done much of this type of work before, I’ve started the process of becoming a MOTU by working with a mentor, Robert Ancell. Robert has helped me with the process, pointed out mistakes, and suggested packages to work on and has been a big help along the way.
So why do I want to become a MOTU? Personally, my motivation has several aspects:
I started this process last week by doing some gnome 3.6.0 updates, these were fairly simple, but helped me learn the process and tools. Since then, I’ve done five gnome 3.6.0 updates and three other non-gnome updates (two of which will be waiting until post-quantal to be uploaded).
As I progress in this goal, I’ll make updates on my blog and given an overview of some of the tools and processes being used.
If you want to start along the MOTU track there is no better place to start than the MOTU wiki and no better time than when R opens for development in November. While you wait for R to open, I’d recommend you read up on the policies and procedures and maybe make a dry-run through a package that can be updated in R. If you need help #ubuntu-motu on freenode is the place to ask! If you’ve already started, ping me on IRC (mfisch) or leave a comment here, I’d love to have another MOTU candidate to discuss things with and would be happy to assist you as well.