Why a different distribution mechanism

Posted Sep 22, 2011 18:39 UTC (Thu) by otaylor (subscriber, #4190)
In reply to: Managing GNOME shell extensions by alogghe
Parent article: Managing GNOME shell extensions

There are a couple of reasons we want to provide a separate distribution mechanism:

The first reason is that we really do care about users getting a consistent out-of-the-box experience with GNOME 3. We want to be judged on the experience we designed, for good or bad. But in the end, we know that some users, and especially the sort of enthusiastic customizers who read LWN will have other ideas about what works best for them. With extensions we want to give users the chance to go ahead and deeply modify their desktop in all sorts of ways, but we're not so crazy about distributions and OEM's doing the same and presenting the result as GNOME without the user even knowing what been done. extensions.gnome.org is a purely user-focused approach to finding and installing extensions.

The second reason is that extensions are not working with a stable API, so have very specific version requirements that don't really fit into the normal assumptions packaging systems make. If a packaged extension says it works with GNOME Shell 3.2 only and not with GNOME Shell 3.4, then that will likely break the user's attempt to upgrade to the next version of their distribution. We'd rather just disable the extension and let the user find a new version when it becomes available.

But to me, probably the most important reason is simply that we can do better. If someone packages the C library, or Apache, there's a large amount of work to be done to make things work correctly with the system. But at the level where a GNOME Shell extension works, every GNOME version 3.2.1 system looks just about every other GNOME version 3.2.1 system. So why should users have to wait for someone to wrap up an extension in an RPM or DEB in order to use it? Why should an important bug fix be blocked on the same process? Why shouldn't you be able to see the comments and reviews that all users have on an extension?

Why a different distribution mechanism

Posted Sep 22, 2011 22:06 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (2 responses)

Everything else aside for a moment.

I don't see how extensions.gnome.org actually helps GNOME prevent OEMs and distributors from passing off customized deliverables as the authoritative/sanctioned/canonical/orthodox GNOME experience.

There's certainly nothing here which prevents distributors from rolling packaged versions of these extentions and nothing preventing them from pre-installing them as part of the advertised GNOME experience for their distribution.

Distributors and OEMs that want to ship customized GNOME will still ship customized GNOME and call it GNOME. Is there anything I'm not aware of that actually prevents an OEM or distributor from doing exactly the type of out of the box customization you don't want to see and calling it GNOME?

-jef

Why a different distribution mechanism

Posted Sep 23, 2011 17:06 UTC (Fri) by otaylor (subscriber, #4190) [Link] (1 responses)

If we hosted the official GNOME modules and then a whole bunch of extensions all as tarballs to be downloaded from ftp.gnome.org and packaged, then it would be pretty hard to say with a straight face that any combination of those tarballs wasn't equally GNOME.

GNOME doesn't enforce Mozilla-style or event Fedora-style trademark restrictions on the use of the GNOME trademarks with modified versions of the GNOME software, and there never has been much enthusiasm for that in project, but we generally work with the assumption that distributions won't patch up GNOME with arbitrary upstream patches that completely rework the user interface and then claim to be shipping GNOME.

Extensions can completely rework the user interface so it's important to keep a firm distinction in everybody's mind about what's GNOME and what's an extension.

Why a different distribution mechanism

Posted Sep 23, 2011 17:25 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

I understand why GNOME is choosing the technical measures it is making to try to make the distinction. I have nothing to comment on the technical measures GNOME is using to delineate a space between extension and the base.

But I continue to be baffled by where the line in the sand is in regard to allowable downstream customization. How much downstream changes in default UI is too much and still be GNOME? It's never been clear in the 2.x timeframe and I'm still not seeing clarity for 3.x. That lack of clarity is in direct conflict with assumptions you want to make about distributor actions. Without clarity as to what you expect distributors to refrain from doing, they will wander out of bounds again and again without meaning to act in bad faith. Because well, you haven't defined the boundaries of what good faith action is.

I'm not suggesting that you _have_ to pull out the trademark enforcement big stick. But you need some form of clear guidance. You don't even have a compliance test suite or a standing set of "thou shall not" commandments...bright line tests of any sort...which define the narrow path of correct action with regard to what is expected of a downstream vendor who wants to label the deliverable GNOME.

-jef

Why a different distribution mechanism

Posted Sep 22, 2011 23:01 UTC (Thu) by droundy (subscriber, #4559) [Link] (1 responses)

Actually, the version requirements sounds like a strong argument in favor of using the existing distribution infrastructure. That and the security question are sufficient for me to hope that when this is released in Debian stable any integration with browsers allowing remote code to take control of my desktop will be disabled by default.

Why a different distribution mechanism

Posted Sep 23, 2011 17:13 UTC (Fri) by otaylor (subscriber, #4190) [Link]

Want to be clear about "allowing remote code to take control of my desktop" - what happens is that when you click on the website to install an extension, this triggers the downloading code (not in the same process as the browser plugin) to put up a dialog asking if you want to download and install an extension. So, if you consider a MIME-type helper secure, you shouldn't be too afraid of this. The advantage of a plugin, beyond slickness, is that we can do additional security checks to avoid users being tricked by arbitrary websites into installing extensions. Debian of course, is free to package the browser plugin as a separate subpackage.

Why a different distribution mechanism

Posted Sep 23, 2011 0:06 UTC (Fri) by nix (subscriber, #2304) [Link]

The second reason is that extensions are not working with a stable API, so have very specific version requirements that don't really fit into the normal assumptions packaging systems make. If a packaged extension says it works with GNOME Shell 3.2 only and not with GNOME Shell 3.4, then that will likely break the user's attempt to upgrade to the next version of their distribution. We'd rather just disable the extension and let the user find a new version when it becomes available.

Note that FF has the same behaviour, and it's why I have stopped using Firefox. "Upgrade! Lots of new stuff, oh, and security fixes!" <click> "Oops, looks like half your extensions don't work anymore. Oh, you were relying on them? Sorry!"

--- pardon me, that was inaccurate. It doesn't say "sorry".

Why a different distribution mechanism

Posted Sep 23, 2011 1:53 UTC (Fri) by bronson (subscriber, #4806) [Link] (1 responses)

I'm really glad Gnome is embracing the idea of extensions. That said, I think trying to isolate them to some web site will be an exercise in futility.

> We want to be judged on the experience we designed, for good or bad

Remember when Gnome was still shipping Spatial long after all the distros had turned it off? I was really glad the distros could bring their desktops back to reality when the Gnome project decided to get a little too experimental. A second opinion is often a good thing.

Besides, they're going package the good extensions anyway, especially if they're coming straight from Gnome git! http://git.gnome.org/browse/gnome-shell-extensions/ (link from the article)

> So why should users have to wait for someone to wrap up an extension in an RPM or DEB in order to use it?

Because it does an awesome job of weeding out the cruft. You get another pair of eyes, a lively bug tracker, and lots of fellow users all using the same system. Distros tend to be pretty fantastic. Personally, I wouldn't toss their benefits away quite so lightly.

Also, your writing implies that the extensions will have consistent high quality and be continuously maintained... That seems hard to believe. Gnome's past experience with theming sites suggests that the site will contain lots of duplication and half-finished cruft and the distros will cherry-pick the great bits.

> Why should an important bug fix be blocked on the same process?

Most security turnarounds are measured in hours or days. Not a problem.

Wait, you're going to push updates straight to the user??? Or maybe you'll send an email every time something is updated so users will have to click on install links a few times a week? Either way, it doesn't sound very desirable.

> Why shouldn't you be able to see the comments and reviews that all users have on an extension?

Very true! And the Ubuntu Software Center would be one logical place to find those comments and reviews.

Why a different distribution mechanism

Posted Sep 23, 2011 2:28 UTC (Fri) by bronson (subscriber, #4806) [Link]

Sorry, I didn't realize the extent that you were picturing using code review...

> Why should an important bug fix be blocked on the same process?

You're going to hold all code until a qualified reviewer can look at it. Given the endemic shortage of qualified code reviewers, I'm pretty sure the code will be blocked on your site's own reviewers longer than they'll be blocked on some Debian/RedHat maintainer.