ubuntu-appstore-developers team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxx>]

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.

Cheers,



On Thu, Aug 7, 2014 at 9:55 PM, Martin Albisetti <
martin.albisetti@xxxxxxxxxxxxx> wrote:

> Hi all,
>
> It's become clear that we're having a hard time managing the list of
> frameworks across all the different touch points at the current pace
> we're adding them.
> We're making progress towards the tools having update mechanisms, but
> we're still no there yet.
> I was discussing with Loic M. today whether that should live on the
> Sofware Store and exposed as a json api, or in a package in the
> archive. There may be a third better option. Lets decide and get it
> implemented ASAP so we can keep moving forward with less friction.
>
> I don't think I know enough about all the places that list is used to
> be able to strongly advocate for a specific path, so since my
> allegiance lies with the Store, I'd like to throw out the Pros of
> putting it there:
> - Easy to interact with, simple HTTP request and you get back a json
> - Scales out
> - Ultimately, the store accepts or rejects apps based on its knowledge
> of frameworks, so it makes sense for it to have it added first
> - Easy ACLs to allow people to add or deprecate via a web interface
>
> In a nutshell, the way it would work to add, say,
> ubuntu-sdk-14.10-html-dev3, we would:
> - Go to a website with proper ACLs
> - Add it
> - Mark -dev2 as deprecated
> - Trigger an update from reviewer tools
> - Trigger an update to generate the package with the definitions
> - Upload to the archive
>
> I know Loic has a different proposal, so I'll let him propose his.
>
>
> --
> Martin
>
> --
> Mailing list: https://launchpad.net/~ubuntu-appstore-developers
> Post to     : ubuntu-appstore-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers
> More help   : https://help.launchpad.net/ListHelp
>