I think most of the current process is already working well. Submitting my addons to the list and monitoring submissions of other authors already helped me to get useful feedback about "API" changes that I may have missed otherwise. Another big plus is the new transifex service.
The most important issue that I could have with adding my addons to the official repo is what Angelscry already mentioned: not being allowed to support different XBMC versions in the same branch. In this point I think we should differentiate between static files (addon.xml, changelog.txt, ...) and code files.
static files:
If there are changes required in static files (like the versioning change from Eden to Frodo) it is necessary for us to submit two different versions of our addons. In my case I create two tags of the same codebase and just make some manual changes before I send my pull request to the mailing list. This is no big deal but still a bit error-prone.
Maybe we could have a versioning of these files like you already do with the databases. Allowing different versions of these static files being shipped with our addons (addon-12.xml, addon-13.xml, changelog-12.xml, ...)
code files:
In code files it is easy for us to reflect API changes in the code. We could use if/else or even try/except if we want to make sure that our addon is compatible with different versions of XBMC. In my oppinion this approach is easier than maintaining and merging different branches (especially in a hobby project). It would be nice if it could be officially allowed to work like this. I already have some of these constructs in my addons and until now I had no trouble with submitting them to the repo. Not sure if I have just been lucky that it slipped through like this (I hope this does not change from now on
).
About dedicated testing repo:
Although I like the idea I don't think this is absolutely necessary and like jmarshall already stated most users only want to have a test version of their 1-2 favorite addons and don't want to be the guinea pig for every addon dev. If something like this should happen it must be possible to decide what addons should be used from the testing repo. On the other hand every addon dev should be able to create zip files or repos with test versions and provide them in the support thread of the addon. For me this has been the best way to test new releases together with the users and most bugs have been reported before I submitted a new version to the official repo.