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

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno mer, 12/01/2011 alle 11.20 +0100, Olav Vitters ha scritto:
> On Tue, Jan 11, 2011 at 08:59:45PM +0100, Giovanni Campagna wrote:
> > > 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.
> 
> The solution is proper dependencies (what Owen suggested). Relying on
> the exact gnome-shell version. That is how package managers solve this.
> 
> I wonder if you really want to do code reviews? That'll mean a lot of
> extra work. Within Firefox they have this (+sandbox area), but they have
> hired (AFAIK) people to review extensions.

Well, just like gnome-applets, I expect to include only the extensions
that actually work (in the long term something like 15-20), not
everything that someone may have released.
Of course, since there are now very few extensions at all, I will add
them all.

> 
> > 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.
> 
> Problem is that it can completely break gnome-shell. I really wonder if
> people would really expect extensions to be packaged.
> 
> But I guess you already want an extension system to exist (the bells and
> whistles)? A website can still work (GNOME 3.2; later?), installation
> can be handled by some helper app (e.g. somefile.gse; .gse linking to
> the helper app which prompts the user if the extension should be
> installed).

Design on the UI part must be postponed for now, but something
functional (like a tech preview) can be included in 3.0, since most of
code is there.
In the long run, we will see how to provide the best experience, also
considering that loading/unloading extensions currently require to
restart the shell.

> 
> > > 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?
> 
> Because:
> * distributions aren't quick enough with updating extensions
>   (backporting them). Some distributions still package extensions
>   though.
> * there is no guarantee regarding their quality. Tarballs imply that it
>   is supported and quality tested

I agree with the first point, less so with the second. But only time
will tell how dirty and bitrotted extensions will be.

> 
> > >  * 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)
> 
> Nothing precludes one from the other. Getting a Git account means we
> expect someone to stick around for a while and already having made
> a significant contribution. A maintainer should not hand them out just
> to commit some extension.

Agreed. But I was referring to using bugzillas / mailing lists for
patches (which by the way makes for easier review, and since the
component would be shared, it becomes an occasion for improving
gnome-shell core if needed).

> 
> > > 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?
> 
> Just ignore that. The purpose is avoiding one-off repositories and then
> having to spend time archiving those things.

Ok, will create.

Giovanni