Re: Start a gnome-shell-extensions repository / module

[Owen Taylor <otaylor redhat com>]

On Tue, 2011-01-11 at 20:59 +0100, Giovanni Campagna wrote:
> Il giorno mar, 11/01/2011 alle 14.30 -0500, Owen Taylor ha scritto:

[...]

> > But that's not the experience we want with extensions. Installing an
> > extension is like modding your car. You've opened the hood and pulled
> > out some hoses, and now you can plug in the new chip for your engine,
> > and maybe it will give you more power, or maybe it will make your car
> > spew black smoke, and you've accepted that, because if it works you'll
> > be a hero to your friends.
> 
> This will be the experience in 3.0 (for the lack of UI), but I hope not
> for the future. Instead it should be like extensions for Firefox -
> click, wait 5 seconds, restart, enjoy. Everyone uses extensions in web
> browsers, and the the recent discussion about gnome-applets revealed
> that some people have weird needs, but they should not need to find
> $XDG_DATA_HOME for this!

I'm being a little hyperbolic here ... I certainly hope we have a good
collection of extensions that are safe work as advertised. That *don't*
make your computer emit black smoke. And long-term installing extensions
should be very slick - go to a web site, make a few clicks.

But what we do want to retain is the sense that you've actively gone and
chosen not to use not GNOME but rather GNOME *and* the command line
extension for GNOME that pops up an entry at the bottom of the screen
when you press right-shift. (or whatever extension!) We want to keep a
clear line between "shell" and "extensions". And that is best done by
getting the user actively involved in choosing which extensions they
want installed.

> > The "danger" element is why in the long-term I see a web user interface
> > as being essential to this. If the user was looking at a list of
> > extensions in the package installer for their operating system, they'd
> > have no way of knowing which ones were cool and work well, and which
> > ones just make GNOME Shell spew black smoke. Ratings and comments are
> > essential parts of the experience.
> 
> The same applies to normal applications in a package manager (with the
> additional risk of installing stuff that runs as root). But we would
> have code reviews and bug fixes, here and downstream.
> In my opinion, the goal is that the user installs the packaged extension
> if he wants it to "just work", or downloads a tarball from somewhere if
> he wants additional functionality not included in the repository.

I don't really see how an extension can ever "just work" - once we
expand our view of just working to mean not just being secure, and not
crashing, and performing as advertised, but having the right user
interface.

Because if we actually had validated the user interface and it fully
made sense, then it wouldn't be an extension, it would be part of GNOME
Shell. An extension always has a "but"

 * This is a really good CPU load meter for your panel *but* if you
   need to constantly monitor your CPU load so your computer doesn't
   overheat, just get your CPU fan fixed!

 * This is a really good extension to display a command line at the
   bottom of the screen *but* a command line at the bottom of the
   screen just doesn't make sense for most users, and we are doing
   keyboard control with search in the overview.

And so forth.

> > But that doesn't really answer the question of what to do in the short
> > term... I agree that it's not great that people just post links to
> > extensions here and they disappear into the archives.
> > 
> > I think I'm fine if we collect code in a gnome-shell-extensions module
> > in GNOME Git, but we need to the module a bit special - *not* as a
> > standard GNOME module. Maybe something like:
> > 
> >  * No tarballs
> >  * A README file that requests that distributions *not* package it
> 
> Sorry but I don't understand this. The whole purpose of this is having
> extensions in distributors. Why shouldn't they package it?
> (A different matter is installing it by default. And of course when
> installing the package you should start with all new extensions
> disabled, similar to gnome-applets behavior)

We need to know whether the user interface we present is a user
interface for managing extensions the user has already selected or for
selecting new extensions. It makes a big difference to the user
interface:

 - Do we need to explain what the extensions do in detail
 - Should we have a way of showing just the enabled extensions?

If installing a gnome-shell-extension package installs 20-25 disabled
extensions then the user has to be able to manage those extensions
through the user interface.

I also think that it's going to be confusing in the long term if
extensions can *either* be retrieved by you through a web interface or
installed or installed by your distribution.

(There are some cases where pre-installed extensions make sense - e.g.,
someone configuring a set of workstations in a corporate environment
might want to customize them in a uniform fashion. And maybe you'd
put an extension in a package to manage it in that environment. But
that's different from a package that bundles together 20 different
extensions and installs them disabled.)

I'm really not too concerned about the details of the
gnome-shell-extensions module in the short term - however it's set up
it's going to be a step forward.

But I think the history of GNOME shows that collections like
gnome-applets don't really work too well. At some point the maintainer
of the module decides they can't take responsibility for maintaining
more code and stops adding stuff, so you get a pretty much random
collection of items. GNOME Shell extensions should be able to compete
with each other on their own merits, on whether they are useful to
users, and not based on whether they happen to be in some central
module.

So I don't think we should think about a gnome-shell-extensions module
as being the equivalent of gnome-applets.

> >  * Maintain it "Linux kernel" style. Suggest that people who
> >    want to contribute to it create branches on github (gitorious?)
> >    and send pull requests to the maintainer. I don't think getting
> >    through the GNOME account process makes sense if you want to
> >    contribute a small extension.
> 
> I don't like this. The gnome-shell-extensions should be the upstream for
> the extensions we ship, not a random collection of stuff developed
> elsewhere. (This includes abusing the "extensions" component of
> gnome-shell bugzilla)

This one is up to you as the maintainer of the module. I don't think it
really makes sense for you to spend a lot of time yourself maintaining
extensions and updating them to work with the shell.

> > Giovanni - if you are volunteering want to create and maintain such a
> > module, please go ahead - that would be a good step forward. :-)
> 
> Yeah, I am.
> Just a question before:
> l.g.o/Git/NewRepository says that a prerequisite is having released at
> least once. Do we count the posts to mailing list as "releases"?
> Or can it skip that requirements, since it is an auxiliary repo for an
> active project?

That requirement is basically there for people who aren't already GNOME
contributors; we don't want to create accounts for people just because
they think they are going to create a cool GNOME program. Since you are
already a GNOME contributor, it doesn't really apply to you. (Of course,
GNOME contributors should also avoid littering GNOME Git with nearly
empty modules ... not an issue here.)

> > 
> > The other important piece here that we don't have is versioning. I'd
> > really like it to work the same way as Firefox extensions. You have to
> > declare what versions you work with, you aren't allowed to declare that
> > you work with all future versions, and if the shell is upgraded, and an
> > extension isn't marked as compatible with the new version, it just stops
> > working.
> 
> Well, that's just a bug. We have metadata in extensions, we need to add
> to it.

I see you've submitted patches now. Cool :-)

- Owen