On 08/19/2014 07:01 AM, Daniel Holbach wrote: > Hello, > > On 14.08.2014 16:59, Loïc Minier wrote: >> A different approach would be to do something like the distro-info-data >> package, centralizing the data about frameworks (past and present) in a >> single place. >> >> The main advantage would be the usual ones with packages: >> - uses our archive as a VCS >> - same upload/landing process as other packages >> - acl is the usual upload permission >> - allows landing the rebuilds of the various packages depending on the >> framework at the same time as the new framework >> - keeps archive/frameworks separate from any network dependency >> >> Cons: >> - have to go through our non-trivial landing process >> - have to get the data for the store from the archive or bzr >> >> I think the two approaches allow for the same end goal, just in >> different styles; one is more "web development" style with a dump in the >> archive, the other is more Debian style with an archive extract into our >> web side. I dont have a strong preference. > > In our discussion in the hangout yesterday > (https://www.youtube.com/watch?v=XDrm1OL-oVY) we took the following notes: > > - Could either be store or a package as the canonical > authoritative source > - Should decide based on requirements > - Notes from last framework update by slangasek > https://wiki.ubuntu.com/Click/Frameworks/UpdateProcess > - Jamie says: it might be good to also store the apparmor json and > the upcoming platform-api json in the same place (ie, the > equivalent of the frameworks file for apparmor and platform-api), > cause the apparmor one is currently temporary as well. > interestingly, it points at the click-reviewers-tools branch. > → Discuss on mailing list > > As you can see from the last point, we need to make a decision on this. >
I prefer a URL to a web service otherwise the click-reviewers-tools are back in the same position as we were before that we've been trying to get out of: dependent on a package that gets out of data or needs to be SRUed. I like the idea of the bzr branches that are currently implemented. Why not something like: lp:~ubuntu-core-dev/ubuntu-framework-data/master Then we put frameworks.json and apparmor-easyprof-ubuntu.json in there. It should probably include a README file for what these are being used for. We can then point everything at (note, be sure to use 'https' here): https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-framework-data/master/view/head:/frameworks.json https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-framework-data/master/view/head:/apparmor-easyprof-ubuntu.json -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
