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.albise...@canonical.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : ubuntu-appstore-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
