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

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno mar, 11/01/2011 alle 14.30 -0500, Owen Taylor ha scritto:
> On Tue, 2011-01-11 at 11:32 -0600, Jason D. Clinton wrote:
> > On Tue, Jan 11, 2011 at 08:06, Giovanni Campagna
> > <scampa giovanni gmail com> wrote:
> >         Also, GNOME Shell is currently very unstable, both in API,
> >         implementation and design, meaning that extensions written for
> >         2.91.4
> >         may not work with 2.91.5 or 2.91.6.
> >         
> >         For these reasons, I'm proposing to open a new repository on
> >         GNOME Git,
> >         called gnome-shell-extensions, collecting useful, or less so,
> >         extensions, that would be characterized by clean code with
> >         reviews from
> >         Shell developers (including porting after API breaks),
> >         thorough
> >         translations and increased marketing (possibly with
> >         distribution
> >         packages), while still allowing for UIs that don't agree with
> >         current
> >         design.
> > 
> > This has been discussed in the past and it was generally agreed that
> > extensions should be kept *inside* the GNOME Shell repo. until there
> > is a stable API. At that point it would make sense to have an external
> > repo. The rationale given for keeping them inside, while the API is
> > unstable, is that any API changes that affect extensions would
> > immediately show up in runtime testing.
> 
> I don't particularly remember that conversation. I think the problem
> we'd have with keeping extensions inside the shell repository is that it
> would imply that they were "UI options" - that they should be packaged
> by distributions, installed with the shell, and that the user goes into
> a preferences dialog to turn them on.

I have the same opinion here. Extensions are for things that are not
part of the normal GNOME Shell user experience, they should live outside
of the gnome-shell tarball.

> 
> 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!

> 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.

> 
> 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)

>  * 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)

> 
> 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?

> 
> 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.

Giovanni