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 _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
