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

[Olav Vitters <olav vitters nl>]

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.

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

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

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

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

-- 
Regards,
Olav