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. 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.
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.
Attachment:
signature.asc
Description: This is a digitally signed message part