On Tue, Apr 2, 2013 at 9:24 AM, Emmanuele Bassi <[email protected]> wrote:

> hi;
>
> I think I've been harsher than necessary — mostly due to my
> misunderstanding. it was not my intention, and I apologize for that.
>

No worries.  It seems that I have given the impression that GNOME would
take on the tasks of porting extensions instead of having extension writers
do it.  That is was not my intent.


> On 2 April 2013 13:07, Emmanuele Bassi <[email protected]> wrote:
>
> > On 2 April 2013 06:45, Sriram Ramkrishna <[email protected]> wrote:
> >
> >> We've been having some discussions in the marketing team regarding
> frequent
> >> (and valid) criticism regarding the availability of extensions after a
> >> release from the community at large.
> >
> > the "community at large" being...?
> >
> > also, why is marketing-list involved at all? I don't think the
> > marketing team should be the first line of defence when it comes to
> > developers and users relations — mostly because of the size of the
> > marketing team.
>
> I'd like to clarify this: I think the marketing team is in the right
> place as an interface with the GNOME community and its developers, as
> an extension of their work to improve the communication channels
> between the project and its users; I'm less sure about them having the
> resources to care about development issues — we do have venues for
> discussing (and/or bikeshedding) technical issues already. it's great
> to raise the issues on those venues, which Sri has done, so thanks; my
> feeling is that there are a *ton* of communication issues that should
> be addressed before the stability of the internal Shell API with
> regards to extension points than can effectively turn a User
> Experience from the current design to something that looks like GNOME
>

We aren't worried about development issues.  We (and mostly I here) am
passing on a concern and then suggesting a simple solution of providing an
image and some structure.

This will likely become less of an issue as you rightly pointed out as the
API stablizes and extensions do not break from one release to another.  The
image is still useful for gathering community feedback prior to the
release.  It's not our usual modus operand and we would probably be the
first project to do it.  But then we are the first project to use designers
and have them central to our software, isn't it?


> 2 — in other words: with great power comes great responsibility, and
> that includes extension developers. ;-)
>
> this particular issue has been raised multiple times already, and it's
> something everyone even tangentially related to working on the shell
> is acutely aware of. :-)
>
>
Indeed.  I'm trying to put it out in the open and have a casual
conversation about it. :-)


> I think people take for granted, these days, the extensions in
> Firefox, and either weren't there or just forgot the misery that was
> upgrading your browser during the early days; the situation has
> improved *a lot*, but mostly it's just that time has stabilised the
> internal interfaces available to the developers of extensions — and
> GNOME Shell hasn't had 15 years to grow yet.
>
>
This is an excellent point and I re-iterated it above.  This problem
generally goes away when the API stablizes.  But I suspect that we are
quite a few releases out for that.

my point about having a proper "developers channel" dovetails with the
> Testable/GnomeOS/OSTree effort, so I think a lot of the current issues
> with regards to QA and development churn and friction are going to be
> solved, or at least addressed, by that.
>
>
You and I are on exactly the same page here.  I do not see any disagreement
here.  Having that image as  a way to test is going to solve it.  The only
thing I'm adding is we provide some organization and leadership.

sri


> ciao,
>  Emmanuele.
>
> --
> W: http://www.emmanuelebassi.name
> B: http://blogs.gnome.org/ebassi/
>
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to