Category Archives: GNOME

October miscellany

It’s been a wild October!  It started with us releasing Geary 0.4 and Shotwell 0.15, and then a whole lotta more stuff happened.  Some quick bits regarding the past four weeks (or so):

Montreal Summit

Parc La Fontaine
Parc La Fontaine

I’d like to extend my (belated) thanks to everyone who organized and hosted the Summit this year, it was a great event!  Thank you Savoir Faire Linux for organizing everything and CRIM for hosting all of us.  Lots of familiar faces and some new ones too.  In particular it was good to hear about GTK/GLib things to come, like GNotifications and a formal model for GtkListBox, both things we’d like to take advantage of in Geary.

Montreal is a beautiful city and fortunately I had a chance to explore it before the Hackfest opened.  I’m pleased to report that while there I enjoyed what sounds to be the Montreal culinary trifecta: bagels, smoked meat, and poutine.

We’ve moved (physically)

CC BY 2.0 ~ Gary Soup
“Enjoy some spicy food”

Yorba resided in San Francisco’s Mission District for over four and a half years, but the time has come for a change.  We’ve been selling off furniture, cleaning off desks, and boxing up things for our big move, which happened today.  Fortunately the move was painless and quick, and we’re now settled in our new office on the hairy edge of the Financial District down the hill from Chinatown.  (We celebrated finishing the move with a great meal at Henry’s Hunan; go see this fellow, who has eaten and reviewed every item on their menu to teach himself Tomcat.  That floors me for a lot of reasons.)

Unfortunately the preparations for the move has taken our attention off of patches and coding, but that should soon change now that we’re settled.

We’re moving (virtually)

Coincidentally, Yorba is also moving virtually — we’re transitioning from our self-hosted server to (tada!) the GNOME infrastructure.  Yes, soon all of Yorba’s projects will live under the GNOME umbrella.  We’re starting small to work out the kinks, but by the end of the process Shotwell, Geary, Valencia, and gexiv2 will be available at gnome.org.  More information coming soon as things firm up.

Recent GNOME work you might be interested in

Jim Nelson - CC BY-SA 3.0

Yorba recently received funding from Adam Dingle toward fixing a smorgasbord of bugs in the GNOME ecosphere — from gedit to Epiphany to Nautilus to GTK, and more.  The quantity of tickets (over fifty!) and the breadth of the applications they covered meant we needed to find someone with a particular affinity for the depths of GTK and GObject.  Fortunately, we found such a person in Garrett Regier, who’s been doing a smash-up job the past few weeks knocking down these particularly aggravating bugs.

To give a taste of some of the fine work Garrett’s been up to:

As you can see, most of these so far are annoyances, but long-standing annoyances that can make the user feel there’s something not quite right.  Some were down-right maddening.  Consider the over-enthusiastic file chooser bug.  As time went on, its reporter “trained” himself to work around it.

Garrett is still at work on Adam’s list and so more fixes should be dropping soon.  In addition, we’ve asked Garrett to start working on larger projects, including a Find in All Files gedit plugin that should be more stable and easier to use than the currently existing alternatives.  Stay tuned!

 

The Garden of the Forking Paths

A thought experiment:

A software developer decides to write an open-source GNOME desktop application that interacts with any number of Internet services, such as Facebook, Gmail, Flickr, and so forth.  It’s not specific to any one service, however.  The app should take advantage of all the available desktop technologies, not only to leverage all that hard work, but also to be a good desktop citizen.

The first thing the application does is log in to an Internet service.  What should this developer do?

(a) Handroll the authentication code.  Most Internet services use a token-exchange system, but each service is different, so the developer will need to write custom code for all of them.  The user will want the application to save the password for next time, so better look into keyring solutions.  And there’s always the problem of where and how to store long-term tokens, since every service has its own Terms of Agreement.  And don’t forget to request Application Keys — each service has its own.  Some services have different entry points for their various “faces” (i.e. Yahoo! and Flickr) while some have a federated login system (i.e. Google).

Halfway through the process the developer thinks, “Why am I reinventing this wheel?  A lot of applications could use this code.”

Or (b) Use a system library.  The developer calls the library and gets back a token.  No messing around with passwords, keyrings, confirmation Web pages … all that’s handled by the system service.

The developer thinks, “Perfect!  Problem solved and we’re being a good desktop citizen because the user only has to enter their password once.”

(b) seems the obvious choice, right?

Then the developer learns that Ubuntu and most of its derivatives (Ubunten?) use Ubuntu Online Accounts (UOA).  The rest use GNOME Online Accounts (GOA).  UOA and GOA are not API/ABI compatible.

Suddenly (a) looks like an appealing prospect.

This is a poisonous situation for application developers.  It’s not terribly visionary of me to suggest that the number of programs that interact with Internet services — the magical “cloud” — is only going to grow over time.  GNOME and Ubuntu are both acutely interested in attracting more developers (or at least should be).  But new and curious developers arrive and are confronted with this situation.

I speak from experience.  Both Shotwell and Geary could use some kind of Online Account solution today.  Canonical has forked Shotwell to call UOA rather than our handrolled code, but those patches have not migrated upstream, nor could we take them as-is.  Requiring UOA would preclude Shotwell from running on non-Ubunten distros.

I’m not here to argue UOA vs. GOA, or GNOME Shell vs. Unity, or lament that there’s yet-another split on the desktop.  I accept that both sides have decided to go their own ways (here’s Debarshi Ray giving his reasons).  But we at Yorba want Shotwell and Geary to work well — no, work spectacularly — on all GNOME desktops.  That we can’t deal fluidly with something as low-level as server credentials seems absurd.

I once had a professor tell me, “All problems in computer science are solved with a layer of indirection.”  He was being snarky, but there’s a germ of wisdom in that observation.  It seems to me that the solution to the GOA/UOA divide could be solved with a translation or wrapper library.  I’m not thrilled about wrapper code, but sometimes that’s what you’ve got to use.

To throw the first dart at the dartboard, here’s my proposed interface for such a library:

  • Enumerate supported Internet services: Facebook, Yahoo!, Google, etc.
  • Query a particular service for details/capabilities/description/icon/etc.
  • Generate an authentication token for a particular service
  • Launch the login/account registration application (i.e. the GOA/UOA program that takes the user though the steps of logging in to a service and making it available to all applications)

Obviously it’s far more complicated than this, but that’s the gist.  I know GOA is DBus-based, and I believe UOA is as well, so the solution could simply be a DBus interface that both technologies implement, perhaps in the org.freedesktop namespace.  In fact, maybe this should be a freedesktop.org initiative.

We need something.  Asking an application developer (including Yorba) to pick UOA or GOA is a non-starter.  There seems to be a bit of bad blood between the GOA and UOA camps — I don’t know all the details — but I ask both of you to scratch together a bridge rather than fork the path.

Stirring the pond

Copyright Robin Webster (CC BY-SA 2.0)

If you’ve ever submitted a ticket to Yorba, you probably received an email from our Redmine server some time in the last week or so.  I’ve been going through each Shotwell and Geary bug one-by-one in an attempt to circumscribe the rather large, rather muddy pond they’ve grown into.  Each alteration and classification I made triggered emails to the original reporter, the maintainers, commenters, and more.  Thanks for your patience with us.

When I first waded into the ticket pond, Shotwell had something like 980 tickets; Geary, 390.  (I didn’t take notes throughout this process so I don’t have exact figures.)  Today the Shotwell pond is down to 898 tickets; Geary, 363.  That’s a modest 8% reduction, and I haven’t finished the job.  Most of that reduction is from closing duplicate and invalid tickets.  Some were the result of making hard choices.

If you’re a maintainer of an open source project with a large and steadily growing ticket database, I’d like to share what I learned the hard way this week:

Your tickets describe a possible future.  When you leave a ticket open, you’re saying, “Yep, this is something we’d like to do.”  If you’re not planning to fulfill a ticket, close it.  One unneeded ticket just further pollutes an already muddy and large pond and makes more work for you.  A key question to ask yourself is, Does fulfilling this ticket fit into the future we see (or want) for our program?

Watch out for tickets you “kind of” or “might” want to do.  If you use weasel-words to describe your interest in a ticket, that’s a red flag.  Don’t open placeholder tickets either — do you want to do this or not?

Another important question is, If someone submitted a patch for this, would we land it?  You don’t want to open a ticket and then reject a patch someone spent their precious weekends putting together because — whoops! — you don’t want that ugly feature after all.

You might be lukewarm about a ticket and think, “Hey, if someone does the heavy lifting for us, we’ll land their code, no problem!”  Remember: if you take a patch, you’re taking responsibility for that code.  Code you’re “okay” with today could be a nightmare tomorrow, and users don’t like it when features vanish.

Be bold.  Wikipedia’s motto is one of the best pieces of advice given on the Internet, period.  You can’t please everyone, and what’s more, you won’t, so wield an axe when triaging tickets.  Jeff Atwood talks about not letting your users convince you to build a truck when you’re building a car — good advice, especially since they might actually want a car.  Ticket triage is a lot like emergency room triage: each patient is important, but when there’s 980 of them, you turn away the toothaches (which, if you think about it, shouldn’t be in an emergency room).  It’s tough to drop a ticket because there’s always that nagging feeling that maybe we should keep this around…  Remember there are ramifications for keeping a ticket open, as I mentioned already.  Be bold.

… but not too bold. One ticket I thought did not describe the right approach to a problem.  A little push-back from users and a little more digging on my part revealed I’d made a false assumption.  Being bold doesn’t mean not listening or skipping investigation.  Don’t assume a bug’s gone away just because no one’s reported it in a while.  You can’t thoroughly test every case, but at least have some justification beyond inconvenience.

Look for jumping-off points into the pond.  Nine-hundred eighty tickets is a lot of tickets to slog through.  I decided to break down the Shotwell tickets into categories to open up some alternate ways to divvy up the problem.  To date I’ve only categorized about half of the tickets, but even that much was worth it.

The first obstacle I faced was defining “category”.  My first inclination was to think of subsystems as categories.  Soon I realized that associating a bazillion tickets by code location doesn’t really give you the perspective you need.  I decided to concieve of our apps as solving various tasks (“workflow”) and categorize that direction.  For Shotwell (a digital photo manager) I created categories like “camera” (i.e. hardware interaction), “raw”, “import”, “metadata”, “editing”, and so forth.  (If this was the 90s, I’m sure “printing” would’ve made the list.  Today it’s “web-sharing”.)  Not only did this help my immediate problem, it’s also more intuitive for the user who has to pick one when reporting a problem — compare to a user facing such intutive choices as “async” and “cairo”.  I’m still shaking out the categories thing — but again I say, be bold.

All kinds of magic happens with good categories.  Duplicate tickets popped up like flowers in the snow.  Inter-related tickets (potentially solved at the same time) suddenly seemed obvious.  What’s more, obscured problem areas jump out.  Our users are complaining about Shotwell’s duplicate detection (which prevents importing identical files) at various points in the application.  Each ticket was a nit and a theory about the best way to work around it.  Stepping back from them as a whole, I realized these tickets described a broader problem that we should solve as a whole, not in piece-parts.  If we hacked through the tickets one-by-one, we would’ve added a lot of workarounds and unrelated features, creating code complexity and an inconsistent user experience.

One word: Need Information.  A number of the tickets’ comment trails ended with asking the reporter for more information and never hearing back.  Some of these queries were years old, and without that information we legitimately couldn’t move forward to fix the problem.  These tickets I marked as “Need Information” and added a brief comment asking if the reporter could get back to us.  Thanks to email notification some of them did respond, even years after the fact.  Like not leaving open tickets you don’t plan on fixing, no reason to leave tickets open you legitimately can’t fix.  I plan on reviewing the remaining Need Information tickets a few months from now.  If they’re still blocked or unanswered, it may mean it’s time to close.

Stir the pond every so often.  It took a chunk of time, but I feel like we now have a better grasp of the problems we’re really facing, which means getting the changes our users want to them sooner.  This whole exercise took time, but I’m glad I did it.  What’s more, I think it’s something that should happen at regular intervals — every six months, maybe once a year.  Stirring through all the tickets is a good way to sift through the water a bit and see what’s lurking beneath the surface.

Yorba and crowdfunding at LWN.net

Nathan Willis at LWN.net has written a great article summarizing the keynote Adam Dingle and I gave at GUADEC, “Crowdfunding GNOME Application Development” (PDF slides are here).  For those of you who missed the talk, Nathan’s précis gives a nice overview of our presentation and the questions afterwards.  He also offers a concise explanation of today’s problems with funding open source development:

All open source software faces the same challenges when it comes to raising the money to keep developers at the keyboard. In recent years, Linux distributors have underwritten the development of desktop software through the sale of enterprise services and support contracts of various forms. Users have grown accustomed to that situation, and there is certainly nothing wrong with it, but Dingle and his colleagues at Yorba have shown that no one needs to accept that as the only viable funding model.

Read the whole thing here.