ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

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/

Attachment: signature.asc
Description: OpenPGP digital signature