Hello all, I'm Jim Nelson, executive director of Yorba and technical lead of Geary. I've been communicating a little bit with Daniel about the future of Geary. He asked I share my thoughts with all of you.
First of all, I'm excited that Geary is the default mail app for Elementary, the first distro to adopt, which is always an honor. It also represents the kind of risk-taking that smaller distros will take, and I appreciate that. However, as much as Yorba values what Elementary is bringing to the open desktop, we can't target Geary solely for it. More specifically, I'm uncomfortable targeting Geary for Granite. The Granite API seems to be fluid right now. Yorba's policy for all our apps is to build on the current release of our dependencies, as well as the prior release, in the GNOME six-month cycle. In practice, this means depending on the libraries in the current release of Ubuntu and the prior one. For example, right now Geary builds on Precise and Quantal. (It may build on older versions, but we don't guarantee that.) At some point in this cycle we'll move to Raring. Geary *may* build on Precise indefinitely, but if we need something in a library that wasn't available in Precise, then so be it. This model means that our users don't have to be using the absolute latest-and-greatest, but also means we can take advantage of more-or-less the newest stuff. It also means we don't fill our code base with conditionally-compiled patches to support newer library features while maintaining support for older ones. Another policy Yorba adheres to is that we want trunk (master) to build, always. This is quite important to me. So here's our conundrum: Geary today has a sliver of Granite support #ifdef'd in. It compiles under Precise but not Quantal due to some deprecated symbols. I know more work on Granite is coming, which means Geary will fall farther and farther behind without active maintenance. And we do have a number of requests for additional Granite support. The umbrella ticket for that work is at http://redmine.yorba.org/issues/6088 We don't want that to happen. We also don't want to fill Geary with a lot of conditional compilation code to support Granite. So, as I said: a conundrum. What I'm proposing is for a member of the Elementary community to step forward as a Geary champion: someone to actively work on a Granite version of Geary. I propose doing that via two tried-and-true techniques of modern software development: object-oriented code and distributed source control. To break it down: * We'll work with this champion to refactor the Geary client in such a way that subclasses can hook into various events and provide Granite-specific UI elements over generic GTK elements. * This champion will write the Vala code that subclasses Geary's client and calls Granite. * Where this code lives is up for discussion. One path is for this champion to fork Geary (i.e. on Launchpad) and add the Granite code to the fork. Another path is for this code to live in the Yorba repo and is activated via a configure switch. (Yes, this is conditional compilation, but the idea is to conditionally compile in *files*, not fill the existing files with #if's.) We're doing something similar to support Ubuntu's Messaging Menu and Unity task bar. * Elementary will need to build Geary in a PPA that enables this configure switch. * This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API. If the code lives on in the Yorba repo, we'll take those patches more or less as-is. In other words, this champion (and, by extension, Elementary) is taking responsibility for this code. The result of these steps, and the goal of this email, is to (a) make Geary a full-fledged member of the Elementary desktop, (b) keep Geary working on other desktops where Granite is not installed or is an older version, and (c) allow Elementary to make rapid changes to Geary so it represents Elementary's latest efforts. This above is a proposal and not set in stone. Comments and questions are welcome. Thanks, -- Jim
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
