gistfile1.txt

1101   tadzik | lbt, Aard: so there is some work on that architecture graph done already?   
1102     Aard | tadzik: graphing for dependencies of packages, querying live repositories for details
1103   tadzik | I see. The well desired thing seems to be the Big Picture[tm] though, as in "I want to scratch this particular itch, where do I look"
1107   tadzik | as in: is it a particular app, or the jolla sdk, or the part of nemo, or part mer itself
1107   tadzik | does that make sense?
1107     Aard | yes
1109     Aard | so the current approach is: architecture split into hw-adaptation, middleware and ui-level. those are then split into areas (like, backup, connectivity, contacts, ...), containing a
              | few paragraphs with links to additional resources + explanation why it was chosen
1110     Aard | it's cross referenced with a 'technology list', which is split into areas as well, and just contains short details: component name, repository url, license, dependency graph
1110     Aard | at least the 'technology list' could probably be autogenerated by adding a bit of additional metadata to the packages itself
1111   tadzik | sounds good to me
1113      lbt | Aard: I wondered about starting with an associated metadata file outside the packaging (same name) then when it all works, move it to the spec
1113      lbt | much more hackable in the short term
1113     Aard | lbt: works. main thing is, all packages should have that definition, but we'll need a way to pick only a subset up from the documentation
1114      lbt | metadata exclusion ?
1114      lbt | or grouping
1114     Aard | moment
1114      lbt | also - we should define the set of relationships
1115     Aard | http://pastebin.com/9ZrBjDzt
1115     Aard | we should have that documentation available for all mer/nemo packages, but not all of them are supported in the sailfish context
1117   tadzik | well, the nemo ui parts are probably irrelevant
1117      lbt | relationship types ?
1118     Aard | tadzik: they're irrelevant for us, but it'd be kind of an asshole move to exclude components in the same project just because _we_ don't care about them, when they could use the
              | metadata for nemo documentation
1119   tadzik | Aard: agreed
1120        * | lbt suggests using OBS projects as the mechanism to collect packages for metadata - or maybe patterns ?
1120      lbt | projects are easier to script to start with
1121     Aard | lbt: I'd prefer not tying that into OBS too much
1122      lbt | not much, no - just as a way to say "process metadata for these packages"
1122      lbt | almost a pre-phase which makes a package list - that way we can handle nemo or any minimal distro built on mer too
1123     Aard | http://pastebin.com/wP34xvVw -- that's what I currently collect for the technology list
1124     Aard | that info should probably come from the package, but the actual list itself in the architecture documentation