Re: ego website



On Tue, Apr 22, 2014 at 1:48 PM, alex diavatis <alexis diavatis gmail com> wrote:
Jasper, 

> OK, I should come out and say it instead of holding back for so long.

>The extensions website is unmaintained. I am not working on it anymore, and I am not going to work on it. I'm not interested in supporting infrastructure for shell extensions anymore. I do not have the time, nor motivation, nor energy to add any new feature to the website, like a complex auto-karma system like Bodhi.

That is totally okay as long as the site works till we/you/they/somebody deploy a new service. 

I want to asked you a thing though. You are using a browser plugin, and a similar thing I had done a year ago for a theme service. 
I decided to drop the NPAPI for a number of reasons, like unnecessary complexity. So I re-implemented by using a Server/Client model based on NodeJS

This was the way the site was originally architected. We chose to go with an NPAPI plugin for other reasons. I can't remember all of them, but security was certainly brought up. Ports are also a system resource, which means that you can't have multiple GNOME sessions use the website, e.g. if you have a family computer. Unless you shut down the server on VT switch, but that would be awkward.

Now that Chrome and Firefox are killing support for NPAPI, I'm open to other suggestions. Some suggested that we simply drop the installation from the website, and used gnome-tweak-tool instead. Maybe we have a magic link that opens gnome-tweak-tool through a URI handler.

My question here is if GNOME would ever accept Nodejs as a "soft" dependency, the same way you redistribute the browser-plugin.

I'd imagine that if we built a server, it would be in gjs / libsoup instead of node.js. Some of my recent free time has been on building a gjs replacement on top of node.js, so I imagine that both worlds could eventually merge.
 
Anybody who wants to take over maintenance of the site can contact me privately. I am very willing to answer questions about the site's codebase and how it's put together.

I believe a such third party service can do more things, because we aren't restricted for using commercial services eg Google authentication, Disqus etc.
However extensions aren't going to be reviewed on this case, which is kinda an issue as Emmanuele says.

- alex


On Tue, Apr 22, 2014 at 7:05 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:
On Tue, Apr 22, 2014 at 11:16 AM, alex diavatis <alexis diavatis gmail com> wrote:
>a concrete proposal would be to add more people to the pool of
>available reviewers, to reduce the waiting time; this means that we
>should find a way to contact the active and experienced extension
>developers and have them spend some time reviewing other extensions.

Keeping on mind the importance of Shell Extensions for GNOME (users and contributors),
the challenge here is how you can give an extra boost, an extra motivation to people.

>maybe have a pre-review process that is meant to reduce the work load
>of the Shell developers, so that the obvious, time consuming stuff is
>screened first.

Simple and it will work. Using Karma (for authors), having pending-review extensions, and in general all the usual stuffs, might also work. 

Anyway, thanks for your response Emmanuele and I hope you to find a good way to deal with it!

OK, I should come out and say it instead of holding back for so long.

The extensions website is unmaintained. I am not working on it anymore, and I am not going to work on it. I'm not interested in supporting infrastructure for shell extensions anymore. I do not have the time, nor motivation, nor energy to add any new feature to the website, like a complex auto-karma system like Bodhi.

Anybody who wants to take over maintenance of the site can contact me privately. I am very willing to answer questions about the site's codebase and how it's put together.

- alex 



On Tue, Apr 22, 2014 at 5:29 PM, Emmanuele Bassi <ebassi gmail com> wrote:
On 22 April 2014 15:18, alex diavatis <alexis diavatis gmail com> wrote:

> What if 500 extensions with monthly updates?

I strongly doubt this will ever be the case, but giving up and just
letting bad extensions find their way in the machines of our users
because somebody, somewhere, may have written an extension that is not
just a reimplementation of something that was available in GNOME 2.x
and wants *all* users to use it is just not going to happen, as long
as extensions are served from a gnome.org machine. the reputation of
the whole project is staked on not harming our users, or letting third
parties harm them by our omission.

a concrete proposal would be to add more people to the pool of
available reviewers, to reduce the waiting time; this means that we
should find a way to contact the active and experienced extension
developers and have them spend some time reviewing other extensions.
maybe have a pre-review process that is meant to reduce the work load
of the Shell developers, so that the obvious, time consuming stuff is
screened first.

fact is: the amount of people writing code is smaller than the user
base; and the amount of people capable of reviewing code is smaller
than the amount of people writing code. by coupling these two facts
you get that there will always be a certain delay and bottleneck. I'm
not sure how long is the queue for Firefox extensions, but I'm pretty
sure that it's not shorter than the one in the Shell — and Firefox has
more reviewers, as well as more extension developers.

ciao,
 Emmanuele.

> On Tue, Apr 22, 2014 at 4:52 PM, Emmanuele Bassi <ebassi gmail com> wrote:
>>
>> hi;
>>
>> On 22 April 2014 14:40, alex diavatis <alexis diavatis gmail com> wrote:
>> > The question here is why GNOME Devs should explicitly review the
>> > extensions?
>>
>> because extensions run in the same process space as the window
>> manager, which is a privileged piece of software.
>>
>> > Add a notice that we aren't responsible for the quality of extensions
>>
>> this is not a matter of quality: it's a matter of shipping an
>> extension from a gnome.org website that can do whatever it wants with
>> the input and output of your system.
>>
>> > and let users review them.
>>
>> this is even worse than not having anybody reviewing them.
>>
>> > If possible have just some automated tests.
>>
>> it's not possible, unless you can write tools that manage to
>> understand the intent of the code.
>>
>> ciao,
>>  Emmanuele.
>>
>> > On Tue, Apr 22, 2014 at 4:21 PM, Sam Bull <sam hacking sent com> wrote:
>> >>
>> >> On mar, 2014-04-22 at 08:51 -0400, Norman L. Smith wrote:
>> >> > My entry in the queue is recent (less than two weeks ago, there is no
>> >> > personal complaint).  I understand extensions are adjuncts to the
>> >> > shell
>> >> > and other priorities will always come before them.
>> >>
>> >> From what I can tell, it seems that there is only one person reviewing
>> >> extensions. This results in the queue only being reviewed like every 2
>> >> months or something, which causes long delays (I'm just an extension
>> >> dev
>> >> myself). I'm guessing there's just nobody else volunteering to help
>> >> with
>> >> reviews.
>> >>
>> >> Maybe if some kind of public call was put out, it might be possible to
>> >> find more some more reviewers, in order to improve this experience.
>> >>
>> >> _______________________________________________
>> >> gnome-shell-list mailing list
>> >> gnome-shell-list gnome org
>> >> https://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >>
>> >
>> >
>> > _______________________________________________
>> > gnome-shell-list mailing list
>> > gnome-shell-list gnome org
>> > https://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >
>>
>>
>>
>> --
>> W: http://www.emmanuelebassi.name
>> B: http://blogs.gnome.org/ebassi/
>
>



--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/


_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list




--
  Jasper




--
  Jasper


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]