Defining the end-to-end process for commercial apps in Software Center
Our current process for adding a commercial, for purchase item to Software Center is listed here:
However, we still need to better define the QA process, signoff, etc...
[Copied from Gobby document: appdevs-
#. current step
> Work item to improve or eliminate it (copied with [assignee] in "Work items" section)
Process for adding a new application:
0. developer discovers that it's possible to sell applications in Ubuntu at all
> On developer.
1. developer figures out how to contact Randy Linnell (<email address hidden>)
> Organize design and implementation of application submission form
2. a commercial agreement is signed between Canonical and the vendor (>1 week)
> Decide and make public standard application sale terms soon: TODO
- app restrictions/
- will we allow dpkg-diversions / replacement of system parts?
- Canonical's cut
- support obligations (eg life of release)
- contact information/digital signature
- license restrictions
3. application goes into a staging PPA
- not important to automate this cycle
- do you want me to add a 1000 $1 apps randy and move them by hand ?
4. Canonical QA does some sanity QA
- making sure the package doesn't replace the kernel etc
- first step to eliminate this step: vendor submits .deb packages
- rules on what the .deb is allowed to do
- or a simpler tarball in defined format that can automatedly become a .deb
- similar to extras apps, would be nice to share tools
- second step: tool to check .deb packages (cf. "packageme")
- install package in a virtual machine
5. Corporate Services moves package from staging PPA to purchase archive
> admin console containing a button to move package from staging PPA to purchase archive
* LOSA needs to provide API
* parts of this can be self-serve (set price, etc)
6. LOSA enters information (pricing, screenshots, etc...) into Software Center Agent, which makes the product available to users.
Consider for n+1 letting Software Center know when an app update is a security update rather than a normal one (we don't have a security pocket for commercial apps)
Process for updating an existing application:
* currently the same as for a new application
What happens when someone upgrades to the next version of Ubuntu?
* e.g. Skype was incompatible with new platform
* We can tell, before the upgrade, whether an application is available for the next version
- no current code for detecting applications broken after upgrade
- we need to do a better job of presenting which *applications* won't work or aren't available
- though, other operating systems don't do a good job of this either
- however other operating systems update much less than every 6 months
- sometimes in the proprietary world the vendor will put out a new product version for a new OS version, and this is something we can consider supporting/
* Standard messaging for users that commercial software may not work on future versions (Ensured to work on the current version but may not work on future versions.)
> Design presentation for commercial applications when you upgrade the OS
> Implement presentation for commercial applications when you upgrade the OS
What happens for software that wants to replace an existing version of a package?
* It's not common at the moment, but may happen in the future
Commercial availability for things that used to be only available illegal
- rom files
- cbt discs
- keys that unlock a app function
[mpt] On developer.
[mpt] Organize design and implementation of application submission form: TODO
[ranman] Decide and make public standard application sale terms soon: TODO
admin console containing a button to move package from staging PPA to purchase archive: TODO
[mpt] Design presentation for commercial applications when you try to upgrade the OS: TODO
[mvo] Implement presentation for commercial applications when you try to upgrade the OS: TODO