I have been toying with a bunch of apt-proxy-like things since I read jdub’s blog about approx. apt-cacher-ng seemed to be working but tends to wonk out on occasion. I decided to try squid for a bit (because then I could use it to cache other things, not just debs).
So after a while of messing with this stuff I decided “this is dumb, why aren’t the computers just maintaining themselves, I am doing too much work for this crap.” I didn’t want to go computer to computer setting a proxy and I didn’t want to mess around with a transparent proxy so I was just annoyed. (And lazy!)
apt-zeroconf was doing this nice and automatically in the past but it was dead upstream and the website disappeared. Maybe if someone fixed this up this would be a nice little solution for home users with multiple PCs. Ends up that Jeremy Austin-Bardo had written a blueprint and a spec. So I gave him a call and now we have started a project to resurrect apt-zeroconf.
The idea is simple. On your home machines you check a box in the gui someplace, and then all your machines share their apt packages with each other. Which means that on release day you upgrade one machine, and then when you upgrade the others you don’t have to redownload everything again. Nice huh? Combine this with deb delta syncing and you’ve got a nice little bandwidth saving solution.
The project is small so some of the guys from the Michigan LoCo will be looking into this as their summer project. If you know python and avahi we could use your help. Also, something changed in pyinotify that we can’t figure out, so help there would be appreciated. Branch away and feel free to join the team and mailing list for updates.
I’d like to point out Robbie Williamson’s summary of the combined Debian and Ubuntu boot performance sprint, which was held at the Canonical office in Millbank, London, UK.
Though we (as in Ubuntu developers) typically have a presence at Debconf this is the first time I can recall (In my admittedly short memory) a targeted sprint specifically designed for Ubuntu/Debian collaboration on a specific feature. I look forward to seeing the discussions that come out of Debconf9 on this as well as admiring the tartans. I’ll see you guys in Spain!
David has blogged the set of 100 papercuts that we’re shooting to fix for Karmic. As you can see here they are divided into 10 milestones of 10 bugs each. Now we have a nice concrete list of bugs that are attainable.
Please see Jean-Louis Dupond’s bug as an example of Doing It The Right Way(tm) by working upstream. On a related note, the word “Ubuntu” is no longer considered a misspelling.
Please feel to dig into any of these and help the cause.
I checked out Joseph Schmidt’s blog post on reporting bugs upstream and I thought I would respond to clear some things up and explain how we do things around here in Ubuntu land.
Josephs starts off with “I am not trying in any way to pick on Ubuntu. They are just keeping statistics in a way I can put some numbers behind my rant.” Heh, ok, fair enough. However, we do have an Upstream Report where we do break this down by package. This is way more useful to study than the page of ~800 or so pile of bugs.
It would be easy to point at a big pile of bugs and come to conclusions. But let’s look at some of these bugs. Some of these are old, they might be fixed in ubuntu but not in another component; I see a bunch that can be resolved (they’re stale and rotting), I see a bunch that just aren’t very good bugs to begin with. Still, it’s a pile of bugs that need to be fixed or resolved.
However, it’s not just about numbers, it’s about quality and context. If today we told all the bugsquad members to automatically forward every Banshee bug we get to upstream we would overwhelm them with badly reported bugs and actually hurt the project. What we strive to do is to act as a good filter for upstreams so that when they get a forwarded bug report from one of our triagers they get the information they need to fix the bug. Doing this with consistency across an entire project is hard which is why we are always doing training classes during openweek and hug days, targetting upstreaming bugs during hug days, and we even have a page that I trudge through nearly every day where people are leaving links in comments but not linking. I usually send them a mail explaining how to link bugs.
This last week we had a Hug Day with the Empathy folk. Look at that list of bugs, those aren’t a pile, those are a specific targeted set of bugs in context with the hug day – we want to be efficient and get the most bang for the buck, that means looking at “the pile” and prioritizing and figuring out which ones upstream wants to see the most. How do we know which ones upstream wants? Having a QA relationship with the upstream is a great start. In this case we have a wonderful upstream who works with our desktop team to make this work. This is a great example of teamwork, we have many others. We also have some poor ones I am sure. (And if you are an upstream who feels we suck at this, let me know immediately)
What else are we doing? As it turns out, many incoming bugs tend to be of poor quality. It’s not the person’s fault, a good bug report is an acquired skill that needs practice! We have a great tool called Apport that fires off when an app crashes. It has the capabilities to gather information from the user and stick it in a bug report. It’s handy. We want more people to use it because it cuts down on the mundane bug ping-pong discussion. “What version, what distro?” etc. We are making an even more concerted effort to increase apport usage among our users so that the bugs coming in start off being better. When I ask upstreams what they think of apport crashers bugs forwarded to them the result is usually very positive.
Please remember that we are very, very sensitive to turning on something that will autospam an upstream bugtracker, and in my opinion, rightfully so. Forwarding bugs to upstream isn’t fixed with a shotgun, it’s fixed with a scalpel. It takes time to go through those and make sure the right ones get forwarded. We have two guys in Ubuntu that are really good at this, they’re the top 2 reporters of bugs for GNOME last year. This is the kind of activity we want to see across the board and doing this properly is very important to Ubuntu and Canonical – if you’re an upstream and you feel like we can improve in this area, please get a hold of me.
You might have noticed that we’re announcing things a little earlier in a cycle. We’ve got two events coming up that are great for individuals and teams. The first one is the Ubuntu Global Jam. Astute observers will remember this as the event formally known as the Ubuntu Global Bug Jam. We decided that we could make this event even better by including any kind of thing your LoCo can come up with. So you can do a jam on docs, translations, or whatever suits your group best. Maybe an installfest? A trip down to the local University to give talks to students? Anything, just let us know how we can help.
For creative folks we’re returning the Free Culture Showcase. Those of you looking for inspiration can check out the winners last cycle.
Here’s a project that I’m sure will be popular. David Siegel has just blogged instructions on how to tag bugs “that will improve user experience if fixed, is small enough for users to become habituated to it, and is trivial to fix.”
You know, those tiny little nitpick bugs that drive you mad. One of my favorites is this one, which I’ve nominated to the list. David’s post shows you how to do it. Another great example is this bug, which has been driving me mad for a long time.
Now before you go into Launchpad and nominate all your pet bugs, remember that this is a nomination process for trivial fixes. So, for example, in my non-developer eyes my Nautilus bug seems simple. It might end up being complicated, so if your bug ends up not being a papercut (and more of a gaping chest wound) then don’t worry about it, we’re shooting for high-bang-for-the-buck and low-hanging-fruit. Not that non-papercut bugs aren’t important – this is an effort to fix little things, nip and tuck at the corners if you will. Have at it!
On a related note, you can now follow the Ubuntu Design Team on identi.ca – and while you’re at it, please take part in the Ubuntu Usability Study.
My friend Adam Lincoln has been working on a Python implementation of Pal, with one key feature, Google Calendar support.
Finally, a companion to mutt for CLI people. The project is called pygpal, and it’s hosted on launchpad. It has some great features like seperate colors for each calendar, add/delete/edit of calendars, with full sync to Google Calendar.
This was a side project for Adam so he could play with the gcal python API. If it’s useful, please consider contributing to the project, specifically the “first run” experience needs some work. Feel free to branch it and run with the ball.
Join the team and ask questions in the newly minted Ubuntu One forum.
Greetings from Barcelona!
Find information about UDS here.
You can follow along the buzz in realtime with our new lifestream (no need to hit reload!) or you can follow us directly on identi.ca. Many thanks to the folks who made the lifestream page (please leave a comment if you’ve contributed to it!)
And of course, grab the schedule to follow along.
J5 has put out a call for donations for GNOME.
I’ve been a Friend of GNOME for years and I find it to be a great program. You get neat stickers and stuff, but more importantly you help fund GNOME activities and keep the gears running. You can donate at the Friends of GNOME website. Remember that in the US your contributions are tax deductible.
Public Service Announcement: There is now a WINE session for Open Week on Friday 200UTC as well as an Ubuntu Women talk tonight at 2300 UTC.
Also, people have noticed that the Forums session is actually after the final feedback session. That’s due to availability of the presenter, but no worries. Sessions have been hovering around ~300 participants per with the Docs Day hovering around ~350 and Mark’s talk hitting ~400. We’re about half way through and there’s no indication of any slow down yet, so feel free to join us in #ubuntu-classroom on freenode. I’ve purposely tried to not +m the sessions so people asking the questions can follow up and also thank the presenter after. So far, other than the occasional interruption the participants have been well behaved and very collaborative with the sessions, thanks so much for helping us help you!
Ars Technica also has a write up of the popular screen-profiles session.
Special thanks to Jeremy Austin-Bardo from the NY LoCo team for taking care of the logs on the wiki page. As always please feel free to send me feedback (good, bad, or otherwise) on Open Week at jorge at ubuntu dot com.
Starting today we have Mark Shuttleworth Q+A starting in about 20 minutes and going on for 2 hours, then it’s docs day. Join us in IRC, #ubuntu-classroom on Freenode.
Come join us!
https://wiki.ubuntu.com/UbuntuOpenWeek
Here’s a nice little gift from the X team, an updated drivers PPA for those of you who want stable releases of drivers without bleeding too much. Having been one of the folks bitten by Intel X driver bugs this cycle I am glad we have this option available. I have been wondering the past few months what just has been going on with this driver since it has been very frustrating to watch it seemingly regress. Keith Packard from Intel has blogged an update on what’s going in -intel land which makes me feel a lot better.
Also, if you’re an nvidia user and want to help triage some bugs that would be appreciated. Of course, the X team is always looking for gifted people to fight the good fight, check out the wiki find out how to help. Big thanks to Bryce Harrington this cycle, who has been working dreadful hours and soldiering on.
Some things just don’t scale. Like say … #ubuntu. It can be frustrating for people who are looking for help during release as everyone floods this channel, everyone is overworked, there are more people that need help that can provide help, it’s a huge channel so you get a bunch of the bad things that come along with that.
I personally prefer the more personal approach, like the tighter knit communities of our Local Teams. Release time always has a bunch of buzz, and always an opportunity to reach out to new users, even if it’s the person who tried Ubuntu once in a while and then goes away. Today I was thinking that release time should really be like college day in high school. In the US, when you are in your senior year of high school you go to these fairs where Universities have booths and you go and you find out what you want to do with your life. You ask about which schools have the best programs, which ones you can afford, which ones you wish would just go away (*cough* U of M) and all that.
Maybe we should look at using release time as a way for Local Teams to reach out to new users. Instead of piles upon piles of people in #ubuntu maybe we should encourage people to split off into more manageable groups, have people stop by their IRC LoCo booth instead to kick the tires. Maybe us as Local Teams should also strive to take more responsibility for our local users and reach out to them actively to get involved in our channels?
I know some teams are doing this already (and have been for years), please leave a comment on how that’s working out for you. Obviously #ubuntu will always be a huge glorious mess, and watching the craziness during release week is always an excellent tradition. I am interested in reading comments about this.
I am pleased to announce that this cycle’s Ubuntu Open Week will be held the week after Ubuntu 9.04’s release, from 27 April to 1 May on #ubuntu-classroom on Freenode. The sessions take place from 1500UTC to 2100UTC (With a special session on Monday night after-hours)
Ubuntu Open Week is a week full of IRC tutorial sessions on a range of subjects, designed to help people get involved in the Ubuntu community. It is given by many of the brightest, most capable members of the Ubuntu community, and covers a range of subjects including packaging, bug triage, translations, accessibility, automated testing, loco teams, mentoring, Launchpad, desktop team, training team and much more.
There will also be the always popular “sabdfl Q+A” session (Thu 30 Apr @ 15.00UTC) in which you have two hours to ask Mark Shuttleworth, the founder of Ubuntu, your burning questions. Jono and I will also be providing an Introduction and Community Q+A session (Mon 27 Apr @ 15.00UTC) in which you can ask your questions about the community, Ubuntu, Canonical and anything else.
New to this Open Week is nearly an entire day of Documentation team sessions, so now is the time to get involved. The schedule is up, so let’s get started! (A few slots left open, if you want them, holler at me)
I can get in the spirit and start a playoff beard. Looks like Greg DeKoenigsberg is throwing down the gauntlet and calling people out. This works out for me, I didn’t even know Carolina had a hockey team …
Wings over the Bruins in 6 games is my prediction/hope.
It seems people are noticing how much faster 9.04 is at booting.
I happen to have 2 SSD disks, one in my desktop and one in the laptop. I measured both my machines with bootchart, the laptop is set to autologin (I am unsure when bootchart stops measuring or if that matters).
The desktop is a 32gb Samsung SLC drive: 12.54 seconds. Not so bad. This is kind of a mongrel system though, I am always installing and removing things, which is why you see leftover exim stuff. I also use a spinning disk as my /home, but I do symlink things like .gconf and .config that get read on boot to make that fast. (And yes, moving .gconf from the spinning disk to the SSD made a huge difference “feel” wise, I should have measured that.) Either way, it’s not a good candidate for measuring stuff, so take that with a grain of salt.
My Lenovo X200 has an X25-M (Not the faster E mind you) – 7.61 seconds. This is basically stock Ubuntu 9.04 as of this morning. Quite acceptable.
For those of you in the back going “Come on now, you have SSDs, I am just a normal person with normal disks, no fair!” I have an old athlon system in the other room and a hp 2510p laptop with a notoriously slow 4200rpm drive and I notice the difference on both of them. Unfortunately you’re going to have to take my word for it since I never had bootchart installed on them until just now. Even in Jaunty the boot time of the 2510p is 27.98 seconds, just to give you an idea …
Does anyone have a non-working empathy in gtalk? I don’t mean voice and video, I mean normal text chat. I can send messages fine but can’t receive any. People get my messages but I never see a response. It’s as if they never respond.
Searching for bugs has been unfruitful – most of them that mention gtalk are bugs about the voice/video implementation so searching has been cluttered with the wrong bugs. None of my empathy installs work, which leads me to believe that I could have configured them wrong in the account dialog. Any help would be appreciated, especially if you have a bug report to link me to.
Thanks internet!
Kudos to Novell for reviving the iFolder community and project. This was Dropbox about 4 years ago, all done in open source (though the “enterprise” server piece took a bit longer to OSS they did have a simpler open source server that did the trick).
Back in the old days I attempted to package this for Ubuntu with Martin Meredith (iFolder as an open project came out around the same time as Ubuntu, though the older closed product had been around longer) and I recall trying to find out what Novell was trying to do with this thing, and having umpteen calls with people in Novell on behalf of other iFolder community members trying to figure out what was going on with the project; all led to dead ends.
There are still some challenges here (Mono 1.2.6? Seriously?) but I am hoping that this second coming will be more community focused. I am the project owner of the simias and ifolder projects on Launchpad if anyone is interested in getting Debian/Ubuntu packaging going; drop me a line. Thanks to Zonker for pursuing this and thanks to Novell for doing the right thing. Now if only people could get it to build … heh.
Aha! You probably thought I was going to blog about Metallica’s impending Hall of Fame induction this weekend, but I’m not!
I want to talk about the Ubuntu Hall of Fame. This is the place where you can nominate people from around the community who have done great work. It’s not just tied to developers, it can be anyone – maybe that person who mans that booth every year at a show, or the person tirelessly translating applications, or maybe it’s the person that fixed a long standing bug that drove you insane. Just click on the “Nominate Somebody!” and give us a little write up on why you think that person is so special.
Nominate your hero today!
Since the Internet is basically worthless today I’m going to start a meme: Name a team or individual who you think has done an awesome job this cycle in the comments or your own blog. (Of course you’re going to nominate them if it’s one person right?) – my vote goes for the Debian/Ubuntu Mono team.
