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