Managing GNOME shell extensions [LWN.net]

September 21, 2011

This article was contributed by Nathan Willis

The GNOME project is currently readying its 3.2 release, the first update to the re-vamped infrastructure and environment introduced in April 2011. Although many minor enhancements and changes are slated to roll out with 3.2, the one with the greatest potential to affect end users is the extensions mechanism for the GNOME Shell desktop interface.

Background

When 3.0 was released, a large slice of the negative criticism it received centered around the difficulty of customizing GNOME Shell when compared to the GNOME 2.x panel and menu system. The placement and orientation of GNOME Shell's interface elements was fixed; fonts, key bindings, and icons could not be changed; popular informational applets and controls were missing (and there was no facility for bringing them back); there were no UI or window-manager themes, et cetera. A stopgap measure called Gnome Tweak Tool appeared later that restored user control over a number of basic settings, but only for a fixed set of options.

In the meantime, although the GNOME marketing crew maintained that the new distraction-free environment of GNOME Shell would eventually win over the hearts and minds of its critics, when pressed about specific issues GNOME developers often referred users with concerns to the forthcoming extensions mechanism that would make every aspect of GNOME Shell mutable and scriptable with JavaScript and CSS. To those (like myself) with specific UI nits to pick, it sounded like a dream come true, albeit one to arrive at an unspecified point in the future.

In the months since, that extension system has slowly begun to take shape. Initially, individual developers would announce extensions on their personal blogs, which were periodically rounded-up on third-party discussion-and-review blogs. That process made locating them difficult, and knowing which ones to trust dicey. An official collection is now hosted in the GNOME Git repository, currently consisting of nine extensions, but it became clear in recent months that a real extension infrastructure would be needed — to handle hosting public extensions, validating and reviewing code, and providing users with a simple way to install and uninstall their selections from within GNOME.

The foot with a sweet tooth

Sweet Tooth is the codename for the new GNOME Shell extension infrastructure project. The user-facing front end of the system is a planned extension-hosting web site à la Mozilla's addons.mozilla.org, at which visitors can search for and download extensions. The URL for the site is variously reported as extensions.gnome.org or extensions.gnome3.org, although neither is active yet. There will be (at least) two substantive differences between the GNOME extension site and Mozilla's Add-Ons repository, however.

First, GNOME Shell extensions will be bundles of JavaScript and CSS that, when executed, alter the GNOME Shell environment itself — thus, in order to avoid forcing the user to shut down his or her session entirely and restart GNOME, they take effect immediately once downloaded and enabled. These factors raise the undesirable possibility of malicious extensions being delivered from any site that could then seize control of the local machine. While extensions would not run with root privileges, they would still have access to potentially sensitive user data or contain other types of malware payloads.

While one possible solution would be to limit the installation of extensions to a specialized application, the current scheme is to access to the extension site with any modern browser, and use other measures to detect and block malware. A sticking point in this approach is how to permit the site's web application to safely learn which Shell extensions are currently installed (and at which version numbers) in order to present the correct options to the use in the UI (i.e., "Install" versus "Uninstall / Upgrade"); it is also necessary to create a mechanism to actually install extensions from the browser.

To provide those capabilities, some sort of go-between is required, perhaps a local process that can speak HTTP to the browser, although there are of course inherent security risks to running a local server that responds to queries about the local filesystem. On the extension site's side of the equation, the plan is to implement a code review policy with cryptographically-signed uploads of each extension. Reviewers will only be responsible for checking new extensions for malicious behavior, not grading them on importance, functionality, or style.

The GNOME Shell discussion list has been debating several approaches to the extension-signing and review-process pieces of the puzzle. Owen Taylor's preferred plan involves two signatures: one from each reviewer, and a separate one from the site — although he noted that the manual steps could constitute a weak spot.

In theory signatures can offer a layer of security that is independent of the security of the hosting of extensions. It's hard for me to wrap my head around a way to make that practical, if we want to be able to review and approve extensions through the web UI. Schemes I can come up end up with end up with something like: - Reviewers download and review extensions locally, then sign them with their GPG key. - An administrator takes the signed extensions, checks the reviewers signature and then adds the official GNOME signature. That would be very secure, but it also creates manual steps and points of failure that would likely make the system just not work in practice. We shouldn't forget either that our opinion about whether an extension is safe can change over time. A signature only means that that exact code base passed review at one point in time.

Extension security is an issue, but as was noted elsewhere in the thread, it is not a greater security risk than that of running any other desktop application.

The other distinction between the GNOME Shell extension service and Mozilla's is that essentially any aspect of the GNOME environment is fair game for extensions, and is configurable through JavaScript thanks to GNOME 3's pervasive GObject introspection. Firefox and Thunderbird extensions could alter fundamental application behavior, but most do not — they make small changes to tie in a specific new feature or service, or alter a particular behavior.

As the example extensions linked to above show, however, a fair number of GNOME Shell extension authors appear interested in substantially changing the desktop experience. The GNOME Shell team seems to be taking a hands-off approach (noting on the Sweet Tooth wiki page that the project will not endorse or support third-party extensions).

Hopefully making that policy prominent on the extensions site will appease the camp that worries about customization diluting the "GNOME brand," but it does leave open the possibility of mutually-conflicting extensions. So far there appear to be no safeguards in place, although there was some discussion about an SELinux-like permission system. Keeping track of permission sets is primarily a security policy tool, but would also assist in managing collection of extensions.

Right now, when a user downloads an extension, it is unpacked into the $HOME/.local/share/gnome-shell/extensions/ directory, with one subdirectory per extension. The subdirectory name should conform to an email-address-like syntax of the form extensionname@yourdomain.com. The Looking Glass tool is GNOME Shell's JavaScript inspector and debugger, and it can be used to investigate installed extensions (and directly evaluate user-provided JavaScript code).

The developer angle

Looking Glass offers a way for aspiring extension writers to explore the GNOME Shell environment. One can select items in GNOME Shell with the mouse and copy the underlying GObject structure to the Looking Glass evaluator, and there is a special function to slow down animations for easier debugging. But it still is not complete enough to serve as a full development environment.

A bigger issue is that GNOME Shell still lacks comprehensive documentation of its structure, methods, and conventions — despite the fact that such documentation is part of the official roadmap. The extension system is potentially powerful, but the only way for outsiders to learn how to write extensions is to hunt for tutorials and examples on individual blogs. Some of them are quite good, such as Finnbarr Murphy's. But without a real effort to maintain official documentation, they rapidly fall out of date. Providing add-on developers with adequate resources is an area where Mozilla excels with its Mozilla Developer Network sites; GNOME will need to play catch-up in order to grow a healthy GNOME Shell extension community.

Soft landing

Now that the freeze for 3.2 is upon us, and the extensions site is still not up and running, it appears that the framework will be relegated to a "soft-launch" in the 3.2 cycle. Taylor described it as "a bit of a stealth-beta for this release ... something we're still working on, something we don't advertise as a release feature, but something that you can already use."

Perhaps that is for the best. Although the extensibility of GNOME Shell is promising (perusing the extensions already written is quite an experience), the human side of the framework still needs work. One only needs to take a look at the public response to GNOME 3.0 to see how poor messaging can undermine a technical success.

The 3.0 public relations and marketing blitz completely failed to communicate to users and developers that an extension mechanism was in the works, or even a possibility for the future — it got no mention in the release notes, the talking points, or even the design documents. GNOME developers have been talking about GNOME Shell extensions in the run-up to 3.2, but with API documentation and developer outreach still missing in action, the risk is that yet another major release will pass with the project missing an chance to attract coders and strengthen its software ecosystem.

(Log in to post comments)

Managing GNOME shell extensions

Posted Sep 22, 2011 2:38 UTC (Thu) by pabs (subscriber, #43278) [Link]

Yeah, it seems a bit weird to do the whole GObject introspection thing and then not take advantage of that to allow shell extensions in any language. Hopefully this gets fixed in the future.

Managing GNOME shell extensions

Posted Sep 22, 2011 5:58 UTC (Thu) by kragilkragil2 (guest, #76172) [Link]

Hopefully it doesn't. I use Gnome3 on a tiny 9 inch netbook and I hate running simple little tools that use memory like the integrity of the universe depends on them. Limiting the choices developers have will make sure that all extentions are just JS and everything will stay lean, mean and without bloat. I don't care if I have to wait for extentions a few years longer or if I will never get them. If they are really important they will be done in JS othewise I don't want to be bothered with them. If there are crappy Python, Perl, Ruby, Java (insert bloated runtime crap here) extensions there will be less incentive to develop them in JS, which is already there and fairly lean and fast. Millions are invested every year to make JS fast and efficient (compared to the 5 bucks that were spend the last decade to make CPython or Perl fast..(not counting Unladen Swallow etc.))

The Gnome developers intent Gnome3 to be used on resource limited devices and limiting developers to use the tools that are best for user experience is the best way to success(see iPhone).
Gnome3 focus hopefully is more on user experience than on developer experience. In the long run users are much more important. Even developers will cope with crap if the user experience is great.
It's FOSS so you could do whatever, but I hope the Gnome devs have the foresight to not encourage slow bloat.

Managing GNOME shell extensions

Posted Sep 22, 2011 7:46 UTC (Thu) by niner (subscriber, #26151) [Link]

Comparing the top output of the example.js from nodejs.org to an equivalent implementation in Perl using HTTP::Server::Simple:
VIRT RES SHR TIME+ COMMAND
614m 9512 4416 0:00.05 node example.js
28932 6408 2660 0:00.04 perl example.pl

node.js not only uses 1 1/2 times the amount of memory compared to perl, it also needed more CPU time for startup and handling a single request returning "Hello world"

So much for lean and fast compared to bloated Perl runtime crap.

Managing GNOME shell extensions

Posted Sep 22, 2011 8:17 UTC (Thu) by kragilkragil2 (guest, #76172) [Link]

I didn't say that JS was any good, just that there are more resources directed at making it better and that it is _already_running_ and needed in Gnome3. Perl, Python (unless you use some rinter applet), Java etc are not.
So my wish is still just JS extentions nothing else (maybe C and Vala). Everything else is not needed and lets the user experience on resource limited devices deteriorate faster than you get upset when somebody says anything against your favorite scripting language.

Managing GNOME shell extensions

Posted Sep 30, 2011 7:19 UTC (Fri) by jamesh (guest, #1159) [Link]

That isn't a particularly relevant comparison. Gnome Shell already has a JS runtime initialised, so an extension would run within that runtime rather than paying those costs a second time.

Managing GNOME shell extensions

Posted Sep 22, 2011 7:49 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

It's indeed sad to see all this energy deployed into reinventing a software deployment system, for a desktop which is only used on Linux systems, all of which already have their own proven deployment mechanism (called system packages).

It will only lead to more clashes with distributions, and more frustrated users. At least mozilla had the excuse they deploy on proprietary systems where the deployment mechanisms are not open to all.

And it will become even more ridiculous when step2 of the systemd plan goes into effect, and the desktop session gets deeply integrated at the system level. We'll get a schizophrenic desktop which in one hand pretends to have nothing to do with the rest of the system (justifying the need to set up its own deployment channel) and in the other pokes deep inside init and the kernel.

Managing GNOME shell extensions

Posted Sep 22, 2011 13:40 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Gnome runs at least on most unixy systems, i.e., Linux (and a slew of different packaging systems, not all the world is Debian), the BSDs (again, with their own packaging) and AFAIU it is the standard environment on the Solarises or at least their open descendants (yet another weird packaging system, or even several). Integrating extensions into each and every one is a inmense amount of work, and they are resource-strapped as is.

Managing GNOME shell extensions

Posted Sep 22, 2011 9:00 UTC (Thu) by debacle (subscriber, #7114) [Link]

> Why wouldn't I just get these with the rest of the binary packages in my linux distribution?

Just speculating, but it's probably the same as with Firefox plugins. If somebody cares to package them, they get packaged. E.g. I never use any Firefox plugins that are not provided via apt-get.

> On another note, javascript appears to be the only way to do any type of desk extension?

I'm sure, it's only matter of short time, until somebody implements Python or other languages support for the GNOME shell. The idea, that people have to use the one scripting languages already failed with Guile.

Managing GNOME shell extensions

Posted Sep 23, 2011 9:05 UTC (Fri) by ebassi (subscriber, #54855) [Link]

I'm sure, it's only matter of short time, until somebody implements Python or other languages support for the GNOME shell.

no, you cannot mix different virtual machines with different garbage collectors within the same process. GObject simply does not support this because it's insane.

if extensions were to be executed out of process then you would not be able to monkey patch internals, so there are various trade-offs to consider.

Managing GNOME shell extensions

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

no, you cannot mix different virtual machines with different garbage collectors within the same process.

What? Yes you can. I do it all the time. Lots and lots of processes link against both libpython and libperl, which have their own independent virtual machines with their own different GCs. There are even bridges permitting e.g. Python and Lua to talk to each other (both VMs with their own independent GCs). What you have to do is ensure that no piece of data ever ends up traversed by more than one GC, which just means designing the FFI right. (Lua's is designed right for this: I don't know about other languages.)

Managing GNOME shell extensions

Posted Sep 23, 2011 16:21 UTC (Fri) by ebassi (subscriber, #54855) [Link]

What? Yes you can. I do it all the time.What? Yes you can. I do it all the time.

you left out the important bit of my reply: GObject does not allow that. each language binding will have to keep a reference on the native C object, and get notification when the object goes away in the underlying library. GObject only allows one of those notifications because more than one would a) clash with the ABI guarantees (we don't have infinite space in the GObject structure and we cannot add fields without breaking the ABI) and b) would impose performance restrictions (suddenly, object destruction is O(n) with n being the number of "toggle" references).

so, no: GObject does not allow multiple VMs with different GCs in the same process, and that won't change in the short term.

you can get more information in this thread on desktop-devel-list.

Managing GNOME shell extensions

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

That... doesn't seem like the sort of fundamental restriction you were implying. It seems more like a 'we can only think of one way to write a VM' problem. Off the top of my head: it is perfectly possible to do all these things via some sort of central registry which takes the single allowed reference: you'd just need to have all the VMs load some package that cooperated with such a registry. Since the VMs would have to load at least one specialized package in any case (to be of any use as an embedded language), this problem is moot. There is no need for the VMs themselves to cooperate at all. All they need is an FFI that calls out to C and the ability to load modules written in C, which virtually every VM must have if it is to be of any real use.

Managing GNOME shell extensions

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

Actually, it's not just some implementation limitation we decided on. We simply don't know any way to have an object shared by three different garbage collection systems, work right, and not be leaked. (This is under a fairly strict definition of "work right" ... including among other things that the proxy object are persistent - that I can say in Python button.some_property = 5 and that's there even if the last Python reference to the button is dropped, then you get the object back by traversing the widget graph.)

Managing GNOME shell extensions

Posted Sep 24, 2011 12:21 UTC (Sat) by nix (subscriber, #2304) [Link]

Yeah, the only ways to make this work right are

1) maintain a copy of the object inside the separate VMs. This rarely works unless the object has no mutable state (e.g. results of queries).

2) maintain a reference to the object in a proxy, while the object itself remains in C space, not managed by any of the GC systems. If you want a weak link to the C-space object, so the C universe can delete it regardless of the VM's references, you need another layer: a proxy in GCed space pointing to a proxy in C space which then points to the object itself, which ensures that when the C-space object is deleted, you can reseat the C-space proxy to point to a singleton null 'deleted' object, which the VM-resident proxy objects can then use to detect said deletion.

It's far too much work to have the GC systems cooperate, but you can certainly have them stay out of each others' way (and this has been done before, often).

Managing GNOME shell extensions

Posted Sep 22, 2011 10:06 UTC (Thu) by epa (subscriber, #39769) [Link]

Why wouldn't I just get these with the rest of the binary packages in my linux distribution?

Sadly no major Linux distribution provides a way to install software by and for one user. It has to be installed centrally. But desktop extensions, like web browser extensions, are something that individual users need to download and install without affecting other users or needing the root password.

The better answer would be to fix the package mechanism so that one person can 'yum install frozen-bubble', it goes in his or her home directory, and does not affect anyone else; but that's a much bigger problem to solve.

Managing GNOME shell extensions

Posted Sep 22, 2011 19:53 UTC (Thu) by Corkscrew (subscriber, #65853) [Link]

I've always wondered why this is. Has anyone previously tried to add single-user install to the apt? What was the community response?

I realise that Debian is more aimed at big iron, but even there it could be useful. I have webspace and shell on a Debian server, and it is truly painful to do stuff like install Django from source. It would be nice to just have a command like "apt-get install --single-user django" and let magic happen.

Off the top of my head, obvious issues are:
- dependencies would have to be trackable on a per-user basis (which would also mean unprivileged users getting access to the system-wide dependency db)
- you'd need separate locations for system-wide vs per-user installation for every package (this would break some of them)
- per-user installations would have to be convertible to system-wide installations as and when the sysadmin got round to installing stuff

None of these seem insurmountable.

Managing GNOME shell extensions

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

I agree! This would be truly useful.

I'd hope the system would allow users to have their own dependency dbs layered on top of the system's. That way I could add (say) TenGen's MongoDB or Caffeine to my apt sources without affecting everyone on the system.

Packages would probably have to have some sort of indication that user-installable or not. It doesn't make sense to install the kernel into your home directory. Probably x.org too.

It might get weird if the user does a dist-upgrade before the machine admin. Or, if your idea of local installs automatically converting to system-wide ones works, then maybe everything just works.

Managing GNOME shell extensions

Posted Sep 22, 2011 22:57 UTC (Thu) by droundy (subscriber, #4559) [Link]

Why not simply allow users to enable or disable extensions?

Why a different distribution mechanism

Posted Sep 22, 2011 18:39 UTC (Thu) by otaylor (subscriber, #4190) [Link]

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]

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]

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]

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]

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.

Managing GNOME shell extensions

Posted Sep 22, 2011 20:25 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

What I wonder is why they don't use GHNS - http://ghns.freedesktop.org/ - or whatever the latest version is of that... It gets you wallpapers, scripts, extensions, icon themes, emoticons and all that stuff in KDE apps. Guess having a common API and not reinventing the wheel would be worthwhile?