On Sat, 2015-09-05 at 01:51 +0000, Sriram Ramkrishna wrote:
> 1) Document a public api that we know will not be subject to a lot of
> changes. We aren't providing guarantees, but merely that using these
> api that it is going to be unlikely that it will break. We want to
> document it so that extension writers will use them, if they go off
> into the weeds then there is a chance of breakage. At least though it
> will be their decision.
This sounds great. Particularly, if we could make suggestions to what
parts could be prioritised in future versions to be added to this API.
Yes, that's will be up to the gnome-shell maintainers. That said, building an extension community would be a good step. I'd like to see more extension writer presence at hackfests and conferences so we could hash these things out.
For example, my extension adds another view into the overlay, in the
same manner as the apps view. It appears that there is already a
reasonable interface to add extra views in, but it does not extend to
adding a button to the dash to display the view. I've needed to put a
few hacks in place to get a button into the dash, and this won't work
with other extensions that replace the dash with a customised dash. So,
that's something I'd like to see in the API, an easy method to add a new
view to the overlay, with a toggle button in the dash to display it.
That seems like something you should file a bug on? Don't discount the fact that if you can meet devs in person that will go a long way in achieving your goals. :)
> 2) We want to start getting people to start testing extensions prior
> to the final release. GNOME itself is being blamed for the breakage,
> and that might be reasonable if there is some flux. However, some
> extensions break because the version has not been updated (sri raises
> his hand as a guilty party)
This could be good, but there must be a limited number of people testing
extensions, how do I know that my extension will get tested? It could be
a good idea to provide some automated testing. If developers could write
a couple of test cases that could be automatically tested out with each
new release, that would be really good. I'm aware Canonical does this on
their phone platform with a small selection of apps using Autopilot.
We had discussed automated testing, and the methodology would have been to use gnome-continuous and then put in some magic to test the extensions similarly as I described before.
The decision for a bug day was based one more on 1) it's easy to organize and we can start working on the solution immediately. 2) It also has the effect of roping in people to help volunteer and be involved since it doesn't involve anything more than downloading an image and testing the extensions. Having easy tasks and have more community involvement is a desire of mine.
That said, long term we do want to move to automated testing, but that would require some engineering on a QA framework for extensions that we need to figure out. But yes, having unit tests would be great, but I fear that very few extension writers are going to do this, given the fact that a lot of extensions break simply because the authors don't update the versions.
sri
