08:44:58 #startmeeting SailfishOS, open source, collaboration: 24-June @ 10:00 UTC 08:44:58 Meeting started Tue Jun 24 08:44:58 2014 UTC. The chair is cybette. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 08:44:58 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:45:03 #info Welcome to another week of SailfishOS OSS and collaboration meeting 08:45:09 #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-June/004600.html 08:45:16 I'm the meeting chair for today and will be keeping time and order. Please behave and show mutual 08:45:21 respect, and let's have a productive discussion! 08:45:26 #topic Brief introductions (5 min), prefix your information with #info 08:45:28 o/ 08:45:36 #info Carsten Munk, Chief Research Engineer @ Jolla 08:45:48 #info kimmoli, community member, just making some toh's 08:45:54 #info Andrea Bernabei, Nemo contributor and Jolla user 08:45:56 #info Carol Chen, Community chief at Jolla, hatless chair today (again...) 08:45:58 #info Iekku Pylkk�, developer-care @ Jolla 08:46:00 #info Simonas Leleiva, sailor and community member 08:46:19 #info Thomas Perl, sailor and community member 08:46:42 #info Saija Saarenpää, sailfish app developer 08:46:53 #info David Greaves, Mer guy and sailor 08:47:22 #info Eric Le Roux, Bugzilla & TJC admin @ Jolla 08:48:20 anyone else? 08:48:31 prefix your intro with #info 08:48:45 #info Chris Adams, sailor working mainly on sync / SoMe stuff 08:49:01 #info Tomi Virtanen, Software tester @ Jolla 08:49:25 #info Giulio Camuffo, developer at jolla, working mainly on qt and wayland 08:49:48 o/ 08:49:58 #info Thomas Ruecker, community member 08:50:22 #topic Nemo/Mer merge and bugzilla situation, faenil (30 min) 08:50:43 there's a chance this will be much shorted, if there isn't much to talk about :) 08:50:47 faenil: please take the discussion 08:50:51 faenil: sure :) 08:51:00 #info Bob Jelica, spotify employee, community member 08:51:07 so basically, what is the situation with nemo/mer merge? 08:51:15 I remember that weeks/months ago 08:51:25 I heard that this merge would have helped with the bugzilla situation 08:51:27 _middleware_ merge 08:51:37 yes, middleware, thanks tbr 08:51:54 i guess i can take that one -- we're essentially ready to go now on the merging, we had some hiccups on OBS, disks failing, but all things are in place now 08:51:54 when we talked about having a potential bugzilla for sailfish 08:52:01 there was always this nemo/mer thing 08:52:14 and it's an ideal time for it anyway, since also, jolla's devel levelis quiet for the summer 08:52:15 but it seems it hasn't progressed that much since we talked about it 08:52:52 Stskeeps said he'd post instructions so that people could help with the merge 08:52:57 nod 08:53:00 but that was a few weeks ago, I haven't heard back yet 08:53:01 and i failed on that 08:53:04 #info there were hiccups on OBS, disks failing etc. but all things are in place now and ready to go on with the merging 08:53:36 i can promise to let faenil slap me each day i'm not doing something about this topic, there's now no blockers 08:53:46 #info I recently upgraded the OBS to 2.5 (and there's more work to do) but this forms a sane base to continue to develop Mer build infra as we merge stuff 08:53:49 Stskeeps, ahah :) 08:54:12 * phdeswer hands faenil a large trout to use on Stskeeps 08:54:17 #action Stskeeps to post instructions for people to help with the merge 08:54:28 lbt: wasn't there a hiccup with glib versions yesterday? 08:54:44 #info I've been working with Jolla bug people about extending their *internal* bz in a way that helps work better with Mer BZ 08:54:49 #action faenil to take disciplinary actions on Stskeeps if he fails to make progress on this topic 08:54:59 LOL 08:55:02 lol 08:55:12 sledges: it's a consequence of us pointing to a old mer snapshot in nemo:mw 08:55:13 sledges: that problem is due to nemo:mw using an old Mer release 08:55:17 but we're not helping 08:55:34 :)) 08:55:39 I mean mer being a bit stale isn't helping matters 08:55:50 * sledges nods 08:55:52 * lbt still has his toys in his pram :) 08:56:27 are there any plans for making nemo:mw (or nemo:mw:devel?) build against newer mer versions? 08:56:34 or will that be obsolete with the mw merge, anyway? 08:56:51 thp: i think a good talk with the people using nemo:mw to redirect to mer-core:devel would make sense 08:57:03 +1 08:57:25 who are the consumers of nemo:mw today? 08:57:32 i presume glacier, for example 08:57:33 and yesterday I think we agreed to do a Mer release ASAP 08:57:37 there's some cleanup work to be done 08:57:46 yes - was just about to ask 08:57:52 wasn't nomovok also using nemo:mw? 08:57:54 (iirc) 08:57:57 and kde pa? 08:57:57 what's the minimal set to cleanup to do a release? 08:58:01 they had their own homescreen etc 08:58:03 Off topic question: with which intention is Mer written? 08:58:07 sledges: they're currently using an old old nemo version 08:58:11 ok 08:58:18 cybette: FYI, I would like to cover some thoughts on jolla sources (open source licensed) at the end of the meeting. 08:58:18 Stskeeps: action to send that minimal set to ml ? 08:58:19 netchip: www.merproject.org might be a good start, i'll take questions in #mer afterwards happil 08:58:22 y 08:58:43 lbt: no no, i meant cleanup in nemo:* :) 08:58:49 OK 08:59:11 let's go back to the main point 08:59:13 Stskeeps: so then there's anotherissue 08:59:15 tbr: yes, please do if there's time 08:59:19 nemo/mer merge and effects on bugzilla 08:59:21 we need to clean up Mer and do a release 08:59:26 lbt, can you elaborate more on the bugzilla thing? 08:59:33 faenil: sec 08:59:41 so we can begin the mer/nemo merge 08:59:46 so... 08:59:56 I meant we need to say what blocks a release 08:59:59 and then fix it 09:00:02 tbr: we have some updates to cover, and if there is extra time, sure 09:00:03 and then begin to merge 09:00:20 roger 09:00:21 so Stskeeps can I action you to list the blockers 09:01:07 cybette: fyi, shouldn't take more than 2-3 minutes, unless we develop a discussion, but that can be taken elsewhere. it's more of an annoucement. 09:01:26 ofono build and python build error, i think that's about it.. i don't really have much more than that 09:01:36 hard to say at standing foot 09:01:36 tbr: ok, I have 5 min for wrap up and next meeting, we can include the announcement there :) 09:01:45 :) 09:01:52 #action Stskeeps to send a list of blockers-to-a-Mer-release to the ml when he's at desk 09:02:12 #info unless it's just python build error and ofono build 09:02:30 faenil: ok 09:02:35 so bugzilla 09:02:41 i could look into the python build error maybe if there's need 09:02:43 that's got several aspects 09:02:50 thp: I hoped you'd say that 09:03:11 thp, #action it pls :) 09:03:26 #action thp to look into the python build error 09:03:34 Mer Bugzilla; Nemo Bugzilla; SailfishOS public bugzilla; Working with Mer Bugzilla 09:03:39 a link to the failing obs build would be good 09:03:47 #info BZ has several aspects Mer Bugzilla; Nemo Bugzilla; SailfishOS public bugzilla; Working with Mer Bugzilla 09:04:36 also note that some projects have an issue tracker on github, e.g. https://github.com/sailfishos/sailfish-browser/issues 09:04:44 lbt, the whole things relates to sailfish public bugzilla in the end 09:05:06 when we discussed about having a way to report bugs which would actually be easier for sailors to track 09:05:15 while it's not centralized, it's being used right now, and might be useful for those projects that are on github (until we get something better) 09:05:16 it was said that this merge was a prereq 09:05:32 faenil: the Mer BZ will be the public bz for issues in low level sw 09:05:51 and jolla is working on using the public BZ for those issues 09:05:52 lbt, I'm more thinking about 09:06:04 t.j,c is the user level reporting tool 09:06:12 people report bugs on the moderated bugzilla...community guys have a look 09:06:25 if the report is ok, they post it on this bz 09:06:32 and sailors keep track of them 09:06:34 for developers who know what they're doing they can post to Mer BZ 09:06:37 #info in addition to BZ, some projects have issue tracker on github, e.g. https://github.com/sailfishos/sailfish-browser/issues 09:06:38 (and update the status) 09:07:02 lbt, yes but we agreed already that tjc is not ideal for bugs reporting 09:07:18 I wonder how many of the reported bugs are actually filed into the internal bugzilla 09:07:21 faenil: we also agreed there won't be a public bz for bugs :) 09:07:39 but 09:07:39 not really, I remember we agreed we'd look into it once nemo/mer merge was done :P 09:07:43 that's the point 09:07:55 we will use the public bz for sailfishos work 09:08:08 and our internal bz will 'see also' the public bz 09:08:20 our commits will use mer bz bug # 09:08:47 and the changes to internal bz are (afaiui) all OSS 09:08:56 yes, that's cool and all, so: who will file bugs for low level sw? 09:09:00 com'on :) 09:09:03 developers 09:09:14 right, so this is bad 09:09:27 if you have a mer bug and you reference it in t.j.c that's great 09:09:49 what? working on a public, upstream bz is bad? :) 09:09:54 the random user won't report a bug to mer bz.. 09:10:01 yay ... exactly 09:10:08 instead 09:10:11 faenil: random users don't need a bz instance either 09:10:15 the random user should not use bz 09:10:16 eleroux: +1 09:10:32 10 min left 09:10:32 my point is: have users report bugs to bugzilla, and have community pre-moderate those reports 09:10:34 case in point: most TJC users 09:10:47 you can tell me what you want, I don't believe sailors are actually tracking all the bugs reported in TJC, sorry 09:10:48 "but but essenetial killer feature ZOMG" 09:10:48 :) 09:10:53 faenil: tjc, mer bz, github is what we have ATM, not optimal but used and useful and we currently encourage moderators to join 09:10:58 that's step 1 09:11:21 tbr: +1 09:11:22 later we could then evaluate how SailfishOS bz instance makes sense in this picture 09:11:23 faenil: agree that we need to do more triaging in tjc and forward internally where it makes sense 09:11:30 lbt, bugs, not features 09:11:35 bz would be for *bugs* 09:11:36 faenil: users... 09:11:42 lbt, community moderators 09:11:48 faenil: users can't identify bugs 09:11:50 and could possibly be a replacement (though easier said than done) 09:11:51 thp, you can't do that 09:11:52 that does not excuse Jolla from going through all TJC threads and making sure that bugs are extracted and tracked either on Mer or internal BZ 09:12:03 thp, there's too much stuff on tjc for you to be able to track it 09:12:07 faenil: so the moderators can log them on Mer BZ and reference them 09:12:23 faenil: hmm, you are not using the tags? 09:12:26 :p 09:12:36 eleroux, many people probably aren't 09:12:41 faenil: well important issues hopefully bubble up through votes and tags; and sadly unimportant ones we probably don't have the resources for :/ 09:12:46 lbt, no please, we should make life easier, not harder 09:12:47 I suggest to take a few steps back. This is not the first project that deals with such situations. Think Mozilla and the Firefox browser. 09:13:00 lbt, don't ask people to read all TJC threads *and* report the valid ones on mer bz 09:13:05 faenil: I'm not 09:13:20 mozilla also has their TJC, I forgot the name, and they have a BZ 09:13:20 well, "moderators can log them" 09:13:25 look at lessons learned 09:13:39 the key difference though is that Sailfish has significant closed source parts 09:13:45 faenil: my point was that we have a bz for open source code 09:14:01 but even there lessons learned probably can be derived from mozilla tracking bugs in other places 09:14:08 lbt, yes, and that's ok, but we need one for closed source, 09:14:17 faenil: also most users cannot identify the package having problems 09:14:25 they doubly can't for closed source bits 09:14:31 lbt, community moderators 09:14:37 there will "Areas" 09:14:37 and TJC is great for non-bug reports a'la "i'd like to use it like this" or "i can't get this working", where the solution might just be an explanation and no code change. 09:14:40 not "packages" 09:14:45 thp: +1 09:14:59 thp, exactly 09:15:10 tjc is good for that 09:15:12 not for bug reporting 09:15:18 because it's just *too* much 09:15:20 and for nemo middleware, i guess the github issues should be used, as this is kind of "upstream" then 09:15:33 thp: meep ... gitlab 09:15:43 and if you want the proof: let's count how many of the *valid* bugs filed on tjc are being tracked in your internal bz 09:15:46 ETOOMANYTRACKERS 09:15:46 so lets not push github too much just yet 09:15:47 if not, you failed 09:15:50 (5 min) 09:15:52 tbr: yeah 09:16:05 we'll need a tracker to track the tracking in those trackers! ... 09:16:11 tbr: but pulling them all to mer gitlab for mer packages is sane 09:16:18 and then mer bz for them 09:16:22 tbr, nemo always used its bz (which will become mer's) 09:16:24 so no problem there 09:16:38 faenil: I don't know about nemo bz - do we still want it ? 09:16:42 tbr: sup dawg i put a bugzilla into your bugzilla so you can track while you fix? ;) 09:16:45 faenil: I was referring to Mer, Nemo, Github, Gitlab, JB 09:17:05 tbr: yes nemo should go, github should go 09:17:06 lbt, just a Nemo section (with subsections) in Mer bz will do, imho 09:17:11 tbr: mer + tjc only 09:17:18 oh, and by the way, if you have links to valid bugs on tjc, please post them here so we can see them forwarded internally and handled 09:17:23 lbt, yes, mer+tjc 09:17:25 lbt: I understood merging as also "killing" Nemo bz or did I get it wrong? 09:17:28 lbt: well JB won't go away, it's just not visible... 09:17:31 faenil: lets take that to #nemomobile 09:17:35 thp, AH! See?? 09:17:54 eleroux: I thought so but it's for nemo people to decide about glacier 09:18:01 lbt: sure 09:18:03 3 mins left and I think my point wasn't clear yet :( 09:18:16 faenil: it was - you want a jolla bz 09:18:21 (I think?) 09:18:38 lbt, not exactly, mer bz is okay, if it has a Jolla subsection which is moderated by community so crap doesn't get in 09:18:44 and where noobs can report bugs 09:18:52 and moderators will only let in the valid ones 09:18:52 I'm not happy with that from a Mer PoV 09:18:58 and jolla won't be 09:19:03 why 09:19:09 Mer is OSS 09:19:12 if you want it on another website or bz instance 09:19:13 Jolla is not all OSS 09:19:15 faenil: i guess "noobs can report bugs" doesn't work. either you do a good bug report or someone else has to do it for you (figure out what the problem is) 09:19:16 I think this topic warrants more discussions outside of the meeting, and bring it back to the meeting for decisions if needed 09:19:20 jolla has tjc 09:19:22 that's cool, I'm just saying it doesn't make a difference 09:19:24 1 min 09:19:33 hmpf. I'm late again. *reading up* 09:19:33 cybette: wfm 09:19:39 lbt: mozilla BZ also tracks closed source bugs 09:19:44 lbt, should I repeat why tjc is *NOT* working for bugs? 09:20:02 faenil: that's also why on TJC, the barrier to entry is lower. just freeform "forum" style. this then has to be distilled to real bug reports with steps to reproduce, expected and actual results, etc.. 09:20:02 #info BZ discussion to continue after the meeting 09:20:03 faenil: tjc thread? (srsly) 09:20:12 moving on 09:20:18 *nod* 09:20:23 #topic Betatesting program, faenil (20 min) 09:20:34 thp, yes, problem being that since people don't use bugs tags 09:20:41 we'd have to read all the damn threads 09:20:59 faenil: ok, let's continue this after the meeting 09:21:03 while, with a bz, the number of threads to be reviewed would be quite smaller 09:21:21 faenil: let's take the next topic now. I think the BZ issue will need more time than this meeting allows 09:21:31 faenil: #sailfishos 09:21:44 faenil: Betatesting please, thanks :) 09:22:12 #info (from faenil in pirate pad) what is the current situation, and how distant in the future is the reality where people will be able to opt-in for firmwares betatesting just like with the connman fix 09:22:33 yeah, so, I think it'd be cool to have a betatesting program 09:22:38 and I guess everyone agrees on that :D 09:22:44 so, what are the current challenges? 09:22:52 why isn't it done yet, etc 09:23:04 I'm thinking something like 09:23:07 well, as a start, are you talking about a private beta test, or a public one 09:23:18 betatesters (which are selected by Jolla) 09:23:24 (tbd) 09:23:34 weren't they already doing closed beta in the past? 09:23:36 Stskeeps, I think either is better than nothing 09:23:42 fwiw I proposed using the hotfix solution for a not-yet-finished feature to gather feedback but I think it got lost. This is the same issue I think 09:24:00 (I proposed it internally on a bug) 09:24:17 Stskeeps, but my discussion is about an "opt-in" like thing 09:24:37 faenil: so there's no selection if opt-in? 09:24:56 eleroux, yeah, it'd be cool without a selection 09:25:03 (sorry I misexpressed before) 09:25:36 hotfix was opt-in 09:25:42 so, just like the connman thing (but with more disclaimers possibly) 09:25:57 people would say "I want to test it please, I don't care if my phone explodes" 09:26:15 the thing with betatesting is, what do we do if beta software breaks (as it often does)? does it affect warranty? is there a way to recover? is it just for people to play around or do we expect feedback? if feedback, in which form? 09:26:35 exactly 09:26:41 yes, it's tricky 09:27:11 so, about recovery, we know there are ways for that even without the flasher 09:27:20 also, is it just for single features or for early access to full updates? 09:27:30 I'm talking about full updates 09:28:03 faenil: what's the benefit to jolla and users ? 09:28:08 about warranty, Jolla has to decide here, but I wouldn't complain if I were to lose warranty 09:28:11 as it's quite obvious 09:28:19 you get to break your device and we get to fix it? but it's fun :D 09:28:22 imho for app developers it would be nice to get a week headstart for sw updates to test their apps and fix things if the platform changes broke their apps (for non-harbour apps) 09:28:25 lbt, the benefit is clearly that of reporting bugs before release 09:28:29 one point is what to do with the bug reports 09:28:34 or how to take them in. 09:28:40 or also to add support for new APIs into their app, etc.. 09:28:48 faenil: OK - but seriously - do we need that - and do you want to load Jolla up with the cost of doing that? 09:29:07 lbt, let's see what the cost it 09:29:10 lbt: good point 09:29:12 there are also communication concerns - if someone starts raising buzz about a feature (eg, carddav or something, maybe), then testing shows that it's immature so it gets pulled from an update, you have potential for disappointment. 09:29:13 now apis and other stuff - that's *not* update things 09:29:19 Jope, back to point 1) in the meeting ;) 09:29:22 that's opt-in to feature testing 09:29:26 and I like that idea 09:29:27 faenil, ah .. I joined late :-) 09:30:02 hmm, updating? 09:30:02 chriadam, that's not related, we already agreed with soumjya (misspelled) that she'd post the feature at iteration planning, and then rectify when some get cut out 09:30:14 chriadam, so that will happen anyway, if Jolla keeps promises 09:30:21 I know you can send Android's recovery a message, with a path to the update.zip 09:30:32 and it updates the system for you 09:30:42 can phones get so screwed up that recovery can't be used to get back to factory settings? 09:30:44 netchip: we also do updates quite often by comparison 09:30:56 faenil: it's different if someone from the community is using it and saying "omg it's awesome, you are going to love it!" and then we pull it, as opposed to it just appearing as an entry in a list and then explaining that we had to cut it. 09:31:07 cpeake: if you enable root on the phone, yes 09:31:20 cpeake, everything is possible...quite unlikely, but still possible 09:31:26 ok 09:31:27 cpeake: yeah, you could write over the recovery partition or destroy your btrfs 09:31:29 however, then the user overrode the recovery partition 09:31:45 once the magic black smoke gets out, there's no putting it back in. 09:31:58 chriadam, not really imho, there's just a bit more hype, but it's okay as long as you cut it out for quality concerns, people understand 09:32:03 (8 min) 09:32:23 faenil: so .. an alternative idea: 09:32:41 how about community feature testing? 09:32:50 * lbt has community hat on now btw ... 09:32:55 lbt, I'd still like to understand more about the "cost" 09:33:05 lbt, it's often hard to separate features for testing 09:33:08 * tbr has a funky hat on now btw ... 09:33:10 one thing pulls in the other 09:33:11 what about an option 'beta 09:33:17 ' in the developer menu? 09:33:20 lbt, oh wait, let me test the upgrade to Qt5.2 :D 09:33:25 faenil: I can discuss that offline - just standard business operating costs 09:33:50 faenil: I was more thinking about apis 09:33:54 faenil: well basically features are a set of >= 1 package(s) that provide said feature, and that can be done opt-in style 09:33:58 'Enable future features - VOIDS YOUR WARRANTY' or something? 09:34:00 and possibly new features 09:34:16 thp: yes, exactly 09:34:22 we can't do *everything* like that 09:34:32 thp, yeah but you know, when you update one package, it could break another functionality which relies on that, etc...you know that :) 09:34:33 (e.g. a feature in media player might involve changes in the media player app and in audio middleware or tracker) 09:34:35 but some apps are reasonably contained 09:34:39 something like Arch Linux' testing repos 09:34:39 :) 09:34:52 faenil: for things that are really interlinked, say, mce, we can't really do that, anyway. 09:34:53 faenil: that's why you'd be testing it... :D 09:35:00 thp, excatly 09:35:06 but that's okay 09:35:26 so i guess we can leave it at doing opt-in feature testing (like connman) where it makes sense 09:35:32 lbt, so am I testing the feature, or am I testing if you are updating the correct packages so that the rest doesn't break because you only wanted to update part of my OS? ;) 09:35:36 * lbt points out that this is the reason companies have full-time QA .... 09:35:53 and have possible "beta access" to full firmware upgrades maybe at a later date, and then probably only to a select group of people 09:36:02 faenil: I'd suggest that you'd be testing the feature 09:36:03 what about a testing repo? 09:36:06 lbt, instead of exploiting the community for QA (where possible) you're closing the gate 09:36:12 maybe before the design is finalised 09:36:16 bit of rolling release 09:36:21 it may not even get productised 09:36:28 faenil: eh? 09:36:31 netchip: you're coming from a PC perspective, where reinstall is cheap. this won't work. 09:36:34 netchip: for the whole OS or per-feature? 09:36:53 thp: whole OS, and if you want to revert, reset to factory settings 09:37:10 netchip: the best you might get in that sense will be a combination of jolla opt-in and Chum community things 09:37:17 forced downgrade and wipe of data 09:37:18 3 min... do we have some #info or #actions on this topic? 09:37:24 lbt, Jolla is small, it doesn't have enough testers, etc etc...instead of looking for a way to have more people test the firmware, you're covering the opportunity to get free work from community with "business costs" 09:37:26 e.g. the caldav plugin was in Chum for a while before it got released 09:37:28 faenil: I mentioned that 'exploiting the community' is not as easy/cheap to do as you seem to think. It's a genuinely hard problem. 09:37:30 netchip: well, yeah. except we don't have easy means to do a factory reset (i would be much more comfortable with flashable images, but we don't have that for various reasons) 09:37:58 tbr: ah 09:37:59 lbt, then we could discuss "a way to exploit community in a cheaper way" ? 09:38:06 netchip: the other thing is, some updates might change user data (e.g. recent gconf -> dconf migration), so you can't really go back with a full reset. 09:38:16 thp: yeah, that' 09:38:23 faenil: hence my 'feature test' idea 09:38:23 that's why 'voids warranty' ;) 09:38:35 lbt, no, I meant without limiting the testing set :P 09:38:42 err 09:38:44 Just doing suggestions, mighn't make sense 09:38:51 mightn't* 09:38:59 faenil: reduce cost whilst not limiting scope .... neat trick... 09:39:21 lbt, so, you're absolutely sure that having 1000 people test that for free (and maybe 3 of them are good testers) come at a higher cost than hiring 3 testers? 09:39:31 yes 09:39:46 997 sets of false reports that need retesting 09:39:51 #info Opt-in feature testing (like connman) is doable for now, full firmware betatesting still needs feasibility consideration 09:40:07 lbt, not if you let community do that for you, using my idea in 1) 09:40:13 times up for this topic. 09:40:18 oh god 09:40:19 :( 09:40:23 #topic Updates on ambiances/icon packs in Harbour (5 min) 09:40:33 iekku: do you have some upates for us? 09:41:44 work is ongoing on that side 09:41:57 there's some things we need to figure out by ourself still 09:42:22 disclaimer: sailors are starting vacations 09:42:57 so we're looking months rather than weeks? (not a criticism, but a management of expectations) 09:43:05 basically we need to stabilize and document the format of ambiences, so that ambiences created today will still work in future OS releases without breaking, that's one of the things that need doing. 09:43:17 * artemma has heard that Mechanical Turk approach is pretty standard to make sure test reports are consistent. As soon as tests are simple and clear enough 09:43:24 and we need to update sdk and do some serverside work too 09:43:33 * Stskeeps needs to go, sorry 09:43:53 #info work is ongoing, still need to figure out some things internally (including sdk update and serverside work), sailors starting vacations 09:43:55 stephg, i hope we can get this done during summer, but i can't promise anything 09:44:18 that's mostly for ambience (ambiance?) stuff. for icon pack i'm not even sure. 09:44:31 #info format of ambiences need to be stabilized and documented to make ambiences created future-proof 09:44:33 iekku: no problem, just let us know how you're coming along :) 09:45:10 thanks for the updates, next topic 09:45:11 :) 09:45:17 #topic Updates on Silica documentation improvements (5 min) 09:45:27 anyone? 09:45:48