hi Sri; my first suggestion is to look at how Mozilla and the Firefox extension developers community move when it comes to releases of Firefox that may or may not break existing extensions. we should try and adopt the same mechanisms.
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. > What are our current plans for addressing this? I've heard from some > sources that we have a plan. If I recall, we had some talk about porting > the top 10 most popular extensions prior to release. I think we need to do > a little more than that. it would be easier to get more traction if we could get a proper "developers channel" for testing purposes. Firefox extension developers run nightly or aurora builds of Firefox so that it's easy for them to catch regressions or breakage. until such time when we have a proper developers snapshot of GNOME that does not involve building everything up to GNOME Shell via jhbuild, it's going to be very hard to find a solution that either does not scale, or that does not involve massive amounts of work for everyone, either inside or outside the core GNOME developers community. > We should prepare an image for porting extensions prior to code freeze so > that we can give extension writers a chance to port their extensions over. > We should probably put a disclaimer that we reserve the right to modify some > extensions explicitly to make it work with our release. Given that the > license for most extensions is the GPL, this should not pose a problem? > Essentially, I want to bring extension writers in as part of the GNOME > release mechanism. we already have resource scarcity problems as it is, now you want to take over community-driven and community-developed extensions as well? who's going to do that and still be expected to work on GNOME? > If we want to go for gold, we should set up some kind of automatic testing > for extensions just to check out which are immediately broken and needs > active porting and others that show no errors and can be manually tested by > volunteers and bug reports filed against those extensions. that is going to be massively difficult: we can barely test applications, you want to automatically test a compositor and the combinatorial explosion of 10+ extensions that may or may not conflict between themselves? I doubt you can create an automated system capable of doing that; humans will have to be involved — at which point, I'd rather have the extension authors be involved directly, given that they wrote the extensions in question. 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
