08:44:58 <cybette> #startmeeting SailfishOS, open source, collaboration: 24-June @ 10:00 UTC
08:44:58 <Merbot> 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 <Merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:45:03 <cybette> #info Welcome to another week of SailfishOS OSS and collaboration meeting
08:45:09 <cybette> #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-June/004600.html
08:45:16 <cybette> I'm the meeting chair for today and will be keeping time and order. Please behave and show mutual
08:45:21 <cybette> respect, and let's have a productive discussion!
08:45:26 <cybette> #topic Brief introductions (5 min), prefix your information with #info
08:45:28 <sledges> o/
08:45:36 <Stskeeps> #info Carsten Munk, Chief Research Engineer @ Jolla
08:45:48 <kimmoli> #info kimmoli, community member, just making some toh's
08:45:54 <faenil> #info Andrea Bernabei, Nemo contributor and Jolla user
08:45:56 <cybette> #info Carol Chen, Community chief at Jolla, hatless chair today (again...)
08:45:58 <iekku> #info Iekku Pylkk�, developer-care @ Jolla
08:46:00 <sledges> #info Simonas Leleiva, sailor and community member
08:46:19 <thp> #info Thomas Perl, sailor and community member
08:46:42 <matrixx> #info Saija Saarenpää, sailfish app developer
08:46:53 <lbt> #info David Greaves, Mer guy and sailor
08:47:22 <eleroux> #info Eric Le Roux, Bugzilla & TJC admin @ Jolla
08:48:20 <cybette> anyone else?
08:48:31 <cybette> prefix your intro with #info
08:48:45 <chriadam> #info Chris Adams, sailor working mainly on sync / SoMe stuff
08:49:01 <cobu> #info Tomi Virtanen, Software tester @ Jolla
08:49:25 <giucam> #info Giulio Camuffo, developer at jolla, working mainly on qt and wayland
08:49:48 <tbr> o/
08:49:58 <tbr> #info Thomas Ruecker, community member
08:50:22 <cybette> #topic Nemo/Mer merge and bugzilla situation, faenil (30 min)
08:50:43 <faenil> there's a chance this will be much shorted, if there isn't much to talk about :)
08:50:47 <cybette> faenil: please take the discussion
08:50:51 <cybette> faenil: sure :)
08:51:00 <b0bben> #info Bob Jelica, spotify employee, community member
08:51:07 <faenil> so basically, what is the situation with nemo/mer merge?
08:51:15 <faenil> I remember that weeks/months ago
08:51:25 <faenil> I heard that this merge would have helped with the bugzilla situation
08:51:27 <tbr> _middleware_ merge
08:51:37 <faenil> yes, middleware, thanks tbr
08:51:54 <Stskeeps> 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 <faenil> when we talked about having a potential bugzilla for sailfish
08:52:01 <faenil> there was always this nemo/mer thing
08:52:14 <Stskeeps> and it's an ideal time for it anyway, since also, jolla's devel levelis quiet for the summer
08:52:15 <faenil> but it seems it hasn't progressed that much since we talked about it
08:52:52 <faenil> Stskeeps said he'd post instructions so that people could help with the merge
08:52:57 <Stskeeps> nod
08:53:00 <faenil> but that was a few weeks ago, I haven't heard back yet
08:53:01 <Stskeeps> and i failed on that
08:53:04 <cybette> #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 <Stskeeps> 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 <lbt> #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 <faenil> Stskeeps, ahah :)
08:54:12 * phdeswer hands faenil a large trout to use on Stskeeps
08:54:17 <cybette> #action Stskeeps to post instructions for people to help with the merge
08:54:28 <sledges> lbt: wasn't there a hiccup with glib versions yesterday?
08:54:44 <lbt> #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 <cybette> #action faenil to take disciplinary actions on Stskeeps if he fails to make progress on this topic
08:54:59 <tbr> LOL
08:55:02 <faenil> lol
08:55:12 <Stskeeps> sledges: it's a consequence of us pointing to a old mer snapshot in nemo:mw
08:55:13 <lbt> sledges: that problem is due to nemo:mw using an old Mer release
08:55:17 <lbt> but we're not helping
08:55:34 <sledges> :))
08:55:39 <lbt> 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 <thp> are there any plans for making nemo:mw (or nemo:mw:devel?) build against newer mer versions?
08:56:34 <thp> or will that be obsolete with the mw merge, anyway?
08:56:51 <Stskeeps> thp: i think a good talk with the people using nemo:mw to redirect to mer-core:devel would make sense
08:57:03 <lbt> +1
08:57:25 <thp> who are the consumers of nemo:mw today?
08:57:32 <Stskeeps> i presume glacier, for example
08:57:33 <lbt> and yesterday I think we agreed to do a Mer release ASAP
08:57:37 <Stskeeps> there's some cleanup work to be done
08:57:46 <lbt> yes - was just about to ask
08:57:52 <faenil> wasn't nomovok also using nemo:mw?
08:57:54 <faenil> (iirc)
08:57:57 <sledges> and kde pa?
08:57:57 <lbt> what's the minimal set to cleanup to do a release?
08:58:01 <faenil> they had their own homescreen etc
08:58:03 <netchip> Off topic question: with which intention is Mer written?
08:58:07 <Stskeeps> sledges: they're currently using an old old nemo version
08:58:11 <sledges> ok
08:58:18 <tbr> cybette: FYI, I would like to cover some thoughts on jolla sources (open source licensed) at the end of the meeting.
08:58:18 <lbt> Stskeeps: action to send that minimal set to ml ?
08:58:19 <Stskeeps> netchip: www.merproject.org might be a good start, i'll take questions in #mer afterwards happil
08:58:22 <Stskeeps> y
08:58:43 <Stskeeps> lbt: no no, i meant cleanup in nemo:* :)
08:58:49 <lbt> OK
08:59:11 <faenil> let's go back to the main point
08:59:13 <lbt> Stskeeps: so then there's anotherissue
08:59:15 <thp> tbr: yes, please do if there's time
08:59:19 <faenil> nemo/mer merge and effects on bugzilla
08:59:21 <lbt> we need to clean up Mer and do a release
08:59:26 <faenil> lbt, can you elaborate more on the bugzilla thing?
08:59:33 <lbt> faenil: sec
08:59:41 <lbt> so we can begin the mer/nemo merge
08:59:46 <lbt> so...
08:59:56 <lbt> I meant we need to say what blocks a release
08:59:59 <lbt> and then fix it
09:00:02 <cybette> tbr: we have some updates to cover, and if there is extra time, sure
09:00:03 <lbt> and then begin to merge
09:00:20 <tbr> roger
09:00:21 <lbt> so Stskeeps can I action you to list the blockers
09:01:07 <tbr> 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 <Stskeeps> ofono build and python build error, i think that's about it.. i don't really have much more than that
09:01:36 <Stskeeps> hard to say at standing foot
09:01:36 <cybette> tbr: ok, I have 5 min for wrap up and next meeting, we can include the announcement there :)
09:01:45 <tbr> :)
09:01:52 <lbt> #action Stskeeps to send a list of blockers-to-a-Mer-release to the ml when he's at desk
09:02:12 <lbt> #info unless it's just python build error and ofono build
09:02:30 <lbt> faenil: ok
09:02:35 <lbt> so bugzilla
09:02:41 <thp> i could look into the python build error maybe if there's need
09:02:43 <lbt> that's got several aspects
09:02:50 <lbt> thp: I hoped you'd say that
09:03:11 <faenil> thp, #action it pls :)
09:03:26 <thp> #action thp to look into the python build error
09:03:34 <lbt> Mer Bugzilla; Nemo Bugzilla; SailfishOS public bugzilla; Working with Mer Bugzilla
09:03:39 <thp> a link to the failing obs build would be good
09:03:47 <lbt> #info BZ has several aspects Mer Bugzilla; Nemo Bugzilla; SailfishOS public bugzilla; Working with Mer Bugzilla
09:04:36 <thp> also note that some projects have an issue tracker on github, e.g. https://github.com/sailfishos/sailfish-browser/issues
09:04:44 <faenil> lbt, the whole things relates to sailfish public bugzilla in the end
09:05:06 <faenil> when we discussed about having a way to report bugs which would actually be easier for sailors to track
09:05:15 <thp> 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 <faenil> it was said that this merge was a prereq
09:05:32 <lbt> faenil: the Mer BZ will be the public bz for issues in low level sw
09:05:51 <lbt> and jolla is working on using the public BZ for those issues
09:05:52 <faenil> lbt, I'm more thinking about
09:06:04 <lbt> t.j,c is the user level reporting tool
09:06:12 <faenil> people report bugs on the moderated bugzilla...community guys have a look
09:06:25 <faenil> if the report is ok, they post it on this bz
09:06:32 <faenil> and sailors keep track of them
09:06:34 <lbt> for developers who know what they're doing they can post to Mer BZ
09:06:37 <cybette> #info in addition to BZ, some projects have issue tracker on github, e.g. https://github.com/sailfishos/sailfish-browser/issues
09:06:38 <faenil> (and update the status)
09:07:02 <faenil> lbt, yes but we agreed already that tjc is not ideal for bugs reporting
09:07:18 <faenil> I wonder how many of the reported bugs are actually filed into the internal bugzilla
09:07:21 <lbt> faenil: we also agreed there won't be a public bz for bugs :)
09:07:39 <lbt> but
09:07:39 <faenil> not really, I remember we agreed we'd look into it once nemo/mer merge was done :P
09:07:43 <faenil> that's the point
09:07:55 <lbt> we will use the public bz for sailfishos work
09:08:08 <lbt> and our internal bz will 'see also' the public bz
09:08:20 <lbt> our commits will use mer bz bug #
09:08:47 <lbt> and the changes to internal bz are (afaiui) all OSS
09:08:56 <faenil> yes, that's cool and all, so: who will file bugs for low level sw?
09:09:00 <faenil> com'on :)
09:09:03 <lbt> developers
09:09:14 <faenil> right, so this is bad
09:09:27 <lbt> if you have a mer bug and you reference it in t.j.c that's great
09:09:49 <lbt> what? working on a public, upstream bz is bad? :)
09:09:54 <faenil> the random user won't report a bug to mer bz..
09:10:01 <lbt> yay ... exactly
09:10:08 <faenil> instead
09:10:11 <eleroux> faenil: random users don't need a bz instance either
09:10:15 <lbt> the random user should not use bz
09:10:16 <lbt> eleroux: +1
09:10:32 <cybette> 10 min left
09:10:32 <faenil> my point is: have users report bugs to bugzilla, and have community pre-moderate those reports
09:10:34 <tbr> case in point: most TJC users
09:10:47 <faenil> 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 <tbr> "but but essenetial killer feature ZOMG"
09:10:48 <faenil> :)
09:10:53 <eleroux> 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 <eleroux> that's step 1
09:11:21 <lbt> tbr: +1
09:11:22 <eleroux> later we could then evaluate how SailfishOS bz instance makes sense in this picture
09:11:23 <thp> faenil: agree that we need to do more triaging in tjc and forward internally where it makes sense
09:11:30 <faenil> lbt, bugs, not features
09:11:35 <faenil> bz would be for *bugs*
09:11:36 <lbt> faenil: users...
09:11:42 <faenil> lbt, community moderators
09:11:48 <lbt> faenil: users can't identify bugs
09:11:50 <eleroux> and could possibly be a replacement (though easier said than done)
09:11:51 <faenil> thp, you can't do that
09:11:52 <tbr> 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 <faenil> thp, there's too much stuff on tjc for you to be able to track it
09:12:07 <lbt> faenil: so the moderators can log them on Mer BZ and reference them
09:12:23 <eleroux> faenil: hmm, you are not using the tags?
09:12:26 <eleroux> :p
09:12:36 <faenil> eleroux, many people probably aren't
09:12:41 <thp> 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 <faenil> lbt, no please, we should make life easier, not harder
09:12:47 <tbr> 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 <faenil> lbt, don't ask people to read all TJC threads *and* report the valid ones on mer bz
09:13:05 <lbt> faenil: I'm not
09:13:20 <tbr> mozilla also has their TJC, I forgot the name, and they have a BZ
09:13:20 <faenil> well, "moderators can log them"
09:13:25 <tbr> look at lessons learned
09:13:39 <tbr> the key difference though is that Sailfish has significant closed source parts
09:13:45 <lbt> faenil: my point was that we have a bz for open source code
09:14:01 <tbr> but even there lessons learned probably can be derived from mozilla tracking bugs in other places
09:14:08 <faenil> lbt, yes, and that's ok, but we need one for closed source,
09:14:17 <lbt> faenil: also most users cannot identify the package having problems
09:14:25 <lbt> they doubly can't for closed source bits
09:14:31 <faenil> lbt, community moderators
09:14:37 <faenil> there will "Areas"
09:14:37 <thp> 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 <faenil> not "packages"
09:14:45 <lbt> thp: +1
09:14:59 <faenil> thp, exactly
09:15:10 <faenil> tjc is good for that
09:15:12 <faenil> not for bug reporting
09:15:18 <faenil> because it's just *too* much
09:15:20 <thp> and for nemo middleware, i guess the github issues should be used, as this is kind of "upstream" then
09:15:33 <lbt> thp: meep ... gitlab
09:15:43 <faenil> 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 <tbr> ETOOMANYTRACKERS
09:15:46 <lbt> so lets not push github too much just yet
09:15:47 <faenil> if not, you failed
09:15:50 <cybette> (5 min)
09:15:52 <lbt> tbr: yeah
09:16:05 <tbr> we'll need a tracker to track the tracking in those trackers! ...
09:16:11 <lbt> tbr: but pulling them all to mer gitlab for mer packages is sane
09:16:18 <lbt> and then mer bz for them
09:16:22 <faenil> tbr, nemo always used its bz (which will become mer's)
09:16:24 <faenil> so no problem there
09:16:38 <lbt> faenil: I don't know about nemo bz - do we still want it ?
09:16:42 <thp> tbr: sup dawg i put a bugzilla into your bugzilla so you can track while you fix? ;)
09:16:45 <tbr> faenil: I was referring to Mer, Nemo, Github, Gitlab, JB
09:17:05 <lbt> tbr: yes nemo should go, github should go
09:17:06 <faenil> lbt, just a Nemo section (with subsections) in Mer bz will do, imho
09:17:11 <lbt> tbr: mer + tjc only
09:17:18 <thp> 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 <faenil> lbt, yes, mer+tjc
09:17:25 <eleroux> lbt: I understood merging as also "killing" Nemo bz or did I get it wrong?
09:17:28 <tbr> lbt: well JB won't go away, it's just not visible...
09:17:31 <lbt> faenil: lets take that to #nemomobile
09:17:35 <faenil> thp, AH! See??
09:17:54 <lbt> eleroux: I thought so but it's for nemo people to decide about glacier
09:18:01 <eleroux> lbt: sure
09:18:03 <faenil> 3 mins left and I think my point wasn't clear yet :(
09:18:16 <lbt> faenil: it was - you want a jolla bz
09:18:21 <lbt> (I think?)
09:18:38 <faenil> 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 <faenil> and where noobs can report bugs
09:18:52 <faenil> and moderators will only let in the valid ones
09:18:52 <lbt> I'm not happy with that from a Mer PoV
09:18:58 <lbt> and jolla won't be
09:19:03 <faenil> why
09:19:09 <lbt> Mer is OSS
09:19:12 <faenil> if you want it on another website or bz instance
09:19:13 <lbt> Jolla is not all OSS
09:19:15 <thp> 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 <cybette> 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 <lbt> jolla has tjc
09:19:22 <faenil> that's cool, I'm just saying it doesn't make a difference
09:19:24 <cybette> 1 min
09:19:33 <netzvieh> hmpf. I'm late again. *reading up*
09:19:33 <lbt> cybette: wfm
09:19:39 <tbr> lbt: mozilla BZ also tracks closed source bugs
09:19:44 <faenil> lbt, should I repeat why tjc is *NOT* working for bugs?
09:20:02 <thp> 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 <cybette> #info BZ discussion to continue after the meeting
09:20:03 <lbt> faenil: tjc thread? (srsly)
09:20:12 <cybette> moving on
09:20:18 <lbt> *nod*
09:20:23 <cybette> #topic Betatesting program, faenil (20 min)
09:20:34 <faenil> thp, yes, problem being that since people don't use bugs tags
09:20:41 <faenil> we'd have to read all the damn threads
09:20:59 <thp> faenil: ok, let's continue this after the meeting
09:21:03 <faenil> while, with a bz, the number of threads to be reviewed would be quite smaller
09:21:21 <cybette> faenil: let's take the next topic now. I think the BZ issue will need more time than this meeting allows
09:21:31 <lbt> faenil: #sailfishos
09:21:44 <cybette> faenil: Betatesting please, thanks :)
09:22:12 <cybette> #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 <faenil> yeah, so, I think it'd be cool to have a betatesting program
09:22:38 <faenil> and I guess everyone agrees on that :D
09:22:44 <faenil> so, what are the current challenges?
09:22:52 <faenil> why isn't it done yet, etc
09:23:04 <faenil> I'm thinking something like
09:23:07 <Stskeeps> well, as a start, are you talking about a private beta test, or a public one
09:23:18 <faenil> betatesters (which are selected by Jolla)
09:23:24 <faenil> (tbd)
09:23:34 <tbr> weren't they already doing closed beta in the past?
09:23:36 <faenil> Stskeeps, I think either is better than nothing
09:23:42 <lbt> 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 <lbt> (I proposed it internally on a bug)
09:24:17 <faenil> Stskeeps, but my discussion is about an "opt-in" like thing
09:24:37 <eleroux> faenil: so there's no selection if opt-in?
09:24:56 <faenil> eleroux, yeah, it'd be cool without a selection
09:25:03 <faenil> (sorry I misexpressed before)
09:25:36 <lbt> hotfix was opt-in
09:25:42 <faenil> so, just like the connman thing (but with more disclaimers possibly)
09:25:57 <faenil> people would say "I want to test it please, I don't care if my phone explodes"
09:26:15 <thp> 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 <faenil> exactly
09:26:41 <eleroux> yes, it's tricky
09:27:11 <faenil> so, about recovery, we know there are ways for that even without the flasher
09:27:20 <thp> also, is it just for single features or for early access to full updates?
09:27:30 <faenil> I'm talking about full updates
09:28:03 <lbt> faenil: what's the benefit to jolla and users ?
09:28:08 <faenil> about warranty, Jolla has to decide here, but I wouldn't complain if I were to lose warranty
09:28:11 <faenil> as it's quite obvious
09:28:19 <lbt> you get to break your device and we get to fix it? but it's fun :D
09:28:22 <thp> 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 <faenil> lbt, the benefit is clearly that of reporting bugs before release
09:28:29 <Jope> one point is what to do with the bug reports
09:28:34 <Jope> or how to take them in.
09:28:40 <thp> or also to add support for new APIs into their app, etc..
09:28:48 <lbt> 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 <faenil> lbt, let's see what the cost it
09:29:10 <eleroux> lbt: good point
09:29:12 <chriadam> 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 <lbt> now apis and other stuff - that's *not* update things
09:29:19 <faenil> Jope, back to point 1) in the meeting ;)
09:29:22 <lbt> that's opt-in to feature testing
09:29:26 <lbt> and I like that idea
09:29:27 <Jope> faenil, ah .. I joined late :-)
09:30:02 <netchip> hmm, updating?
09:30:02 <faenil> 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 <faenil> chriadam, so that will happen anyway, if Jolla keeps promises
09:30:21 <netchip> I know you can send Android's recovery a message, with a path to the update.zip
09:30:32 <netchip> and it updates the system for you
09:30:42 <cpeake> can phones get so screwed up that recovery can't be used to get back to factory settings?
09:30:44 <lbt> netchip: we also do updates quite often by comparison
09:30:56 <chriadam> 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 <netchip> cpeake: if you enable root on the phone, yes
09:31:20 <faenil> cpeake, everything is possible...quite unlikely, but still possible
09:31:26 <cpeake> ok
09:31:27 <thp> cpeake: yeah, you could write over the recovery partition or destroy your btrfs
09:31:29 <netchip> however, then the user overrode the recovery partition
09:31:45 <chriadam> once the magic black smoke gets out, there's no putting it back in.
09:31:58 <faenil> 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 <cybette> (8 min)
09:32:23 <lbt> faenil: so .. an alternative idea:
09:32:41 <lbt> how about community feature testing?
09:32:50 * lbt has community hat on now btw ...
09:32:55 <faenil> lbt, I'd still like to understand more about the "cost"
09:33:05 <faenil> lbt, it's often hard to separate features for testing
09:33:08 * tbr has a funky hat on now btw ...
09:33:10 <faenil> one thing pulls in the other
09:33:11 <netchip> what about an option 'beta
09:33:17 <netchip> ' in the developer menu?
09:33:20 <faenil> lbt, oh wait, let me test the upgrade to Qt5.2 :D
09:33:25 <lbt> faenil: I can discuss that offline - just standard business operating costs
09:33:50 <lbt> faenil: I was more thinking about apis
09:33:54 <thp> 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 <netchip> 'Enable future features - VOIDS YOUR WARRANTY' or something?
09:34:00 <lbt> and possibly new features
09:34:16 <lbt> thp: yes, exactly
09:34:22 <lbt> we can't do *everything* like that
09:34:32 <faenil> 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 <thp> (e.g. a feature in media player might involve changes in the media player app and in audio middleware or tracker)
09:34:35 <lbt> but some apps are reasonably contained
09:34:39 <netchip> something like Arch Linux' testing repos
09:34:39 <lbt> :)
09:34:52 <thp> faenil: for things that are really interlinked, say, mce, we can't really do that, anyway.
09:34:53 <lbt> faenil: that's why you'd be testing it... :D
09:35:00 <faenil> thp, excatly
09:35:06 <thp> but that's okay
09:35:26 <thp> so i guess we can leave it at doing opt-in feature testing (like connman) where it makes sense
09:35:32 <faenil> 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 <thp> 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 <lbt> faenil: I'd suggest that you'd be testing the feature
09:36:03 <netchip> what about a testing repo?
09:36:06 <faenil> lbt, instead of exploiting the community for QA (where possible) you're closing the gate
09:36:12 <lbt> maybe before the design is finalised
09:36:16 <netchip> bit of rolling release
09:36:21 <lbt> it may not even get productised
09:36:28 <lbt> faenil: eh?
09:36:31 <tbr> netchip: you're coming from a PC perspective, where reinstall is cheap. this won't work.
09:36:34 <thp> netchip: for the whole OS or per-feature?
09:36:53 <netchip> thp: whole OS, and if you want to revert, reset to factory settings
09:37:10 <tbr> netchip: the best you might get in that sense will be a combination of jolla opt-in and Chum community things
09:37:17 <netchip> forced downgrade and wipe of data
09:37:18 <cybette> 3 min... do we have some #info or #actions on this topic?
09:37:24 <faenil> 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 <tbr> e.g. the caldav plugin was in Chum for a while before it got released
09:37:28 <lbt> 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 <thp> 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 <netchip> tbr: ah
09:37:59 <faenil> lbt, then we could discuss "a way to exploit community in a cheaper way" ?
09:38:06 <thp> 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 <netchip> thp: yeah, that'
09:38:23 <lbt> faenil: hence my 'feature test' idea
09:38:23 <netchip> that's why 'voids warranty' ;)
09:38:35 <faenil> lbt, no, I meant without limiting the testing set :P
09:38:42 <lbt> err
09:38:44 <netchip> Just doing suggestions, mighn't make sense
09:38:51 <netchip> mightn't*
09:38:59 <lbt> faenil: reduce cost whilst not limiting scope .... neat trick...
09:39:21 <faenil> 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 <lbt> yes
09:39:46 <lbt> 997 sets of false reports that need retesting
09:39:51 <cybette> #info Opt-in feature testing (like connman) is doable for now, full firmware betatesting still needs feasibility consideration
09:40:07 <faenil> lbt, not if you let community do that for you, using my idea in 1)
09:40:13 <cybette> times up for this topic.
09:40:18 <faenil> oh god
09:40:19 <faenil> :(
09:40:23 <cybette> #topic Updates on ambiances/icon packs in Harbour (5 min)
09:40:33 <cybette> iekku: do you have some upates for us?
09:41:44 <iekku> work is ongoing on that side
09:41:57 <iekku> there's some things we need to figure out by ourself still
09:42:22 <iekku> disclaimer: sailors are starting vacations
09:42:57 <stephg> so we're looking months rather than weeks? (not a criticism, but a management of expectations)
09:43:05 <thp> 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 <iekku> and we need to update sdk and do some serverside work too
09:43:33 * Stskeeps needs to go, sorry
09:43:53 <cybette> #info work is ongoing, still need to figure out some things internally (including sdk update and serverside work), sailors starting vacations
09:43:55 <iekku> stephg, i hope we can get this done during summer, but i can't promise anything
09:44:18 <thp> that's mostly for ambience (ambiance?) stuff. for icon pack i'm not even sure.
09:44:31 <cybette> #info format of ambiences need to be stabilized and documented to make ambiences created future-proof
09:44:33 <stephg> iekku: no problem, just let us know how you're coming along :)
09:45:10 <cybette> thanks for the updates, next topic
09:45:11 <iekku> :)
09:45:17 <cybette> #topic Updates on Silica documentation improvements (5 min)
09:45:27 <cybette> anyone?
09:45:48 <thp> well, not silica itself, but some documentation updates in general. might also partially overlap with the next topic (autodoc)
09:45:57 <sledges> ^ +1
09:46:08 * sledges seen nice progress there :)
09:46:32 <thp> so what i've looked into recently was the nemo d-bus plugin: https://github.com/nemomobile/nemo-qml-plugin-dbus
09:46:48 <thp> reviewing the api, folding stuff together and making it ready to be api-stable and used by third party apps.
09:46:57 <thp> part of that was also documenting the API.
09:47:18 <thp> first i tried with qdoc, but failed, so i took the easy route and went with sphinx instead
09:47:25 <thp> this markup: https://raw.githubusercontent.com/nemomobile/nemo-qml-plugin-dbus/master/docs/index.rst
09:47:28 <thp> gives this doc: http://nemo-qml-plugin-dbus.readthedocs.org/en/latest/
09:47:58 <cybette> #info there is nice progress in documentation updates in general, e.g. in nemo d-bus plugin
09:48:11 <thp> that's not autodoc yet, but autodoc would work similarly (build the documentation directly from git)
09:48:34 <lbt> yeah - obs stuff took me away from that
09:48:51 <thp> about silica documentation in general, i've had a look at it (wanted to use it as template for the nemo docs), but don't think there have been many improvements to the silica docs themselves in recent days
09:49:08 <chriadam> they need Martin's and Joona's attention, and they're busy right now.
09:49:40 <cybette> #info not too many improvements to Silica docs recently, need Martin's and Joona's attention
09:49:52 <thp> oh and i got a link to a nice pdf that is a good visual guide, let me dig it out
09:50:13 <sledges> #link https://raw.githubusercontent.com/nemomobile/nemo-qml-plugin-dbus/master/docs/index.rst
09:50:16 <sledges> #link http://nemo-qml-plugin-dbus.readthedocs.org/en/latest/
09:50:29 <thp> #link https://sailfishos.org/presentations/qtdevdays_beijing_2013_jpetrell.pdf
09:50:54 <cybette> let's bring in the next topic (timing + since it's related)
09:50:58 <cybette> #topic Updates on autodoc situation (5 min)
09:51:42 <cybette> anything specific to autodoc?
09:51:50 <thp> lbt: ^ probably knows
09:53:05 <cybette> if not we can move on to next topic.
09:53:23 <sledges> the host is up, don't know what's under covers
09:53:37 <cybette> or action for more info next time
09:53:39 <thp> yeah, i think "13:03 <+lbt> yeah - obs stuff took me away from that" is what we have on autodoc, i.e. no progress yet due to other obs work
09:53:55 <lbt> nod
09:54:05 <sledges> #info host is up, lbt was engrossed with obs work to do more
09:54:09 <sledges> #linkg http://autodoc.merproject.org/
09:54:11 <lbt> ty
09:54:12 <thp> and let's add it to next time's agenda to see if there has been any progress
09:54:14 <sledges> #link http://autodoc.merproject.org/1;5C
09:54:14 <sledges> :)
09:54:16 <cybette> sledges: thanks :)
09:54:20 <sledges> #link http://autodoc.merproject.org/
09:54:21 <sledges> gar :D
09:54:32 <cybette> :D
09:54:35 <thp> lbt: pressing "a" does nothing :p
09:54:41 <lbt> thp: try again
09:54:55 <cybette> #topic Updates on beta channel in Harbour / API versioning stuff (10 min)
09:54:56 * sledges presses Ctrl+U
09:55:34 <iekku> #info no news
09:55:43 <cybette> ok that was quick :)
09:55:47 <M4rtinK_jolla_> ouch
09:56:13 <iekku> as said ealier, it is coming earliest on august
09:56:14 <thp> given that qt 5.2 will eventually land, API story will be better from then on
09:56:21 <iekku> +1
09:56:49 <cybette> #info this will be available earliest in August as mentioned earlier
09:56:51 <M4rtinK_jolla_> well, it has been like this for quite a while...
09:57:05 <iekku> august = autumn
09:57:10 <iekku> sorry my mistake
09:57:12 <netchip> august = summer :P
09:57:17 <cybette> #undo
09:57:17 <Merbot> Removing item from minutes: <MeetBot.items.Info object at 0x87c5ed0>
09:57:23 <M4rtinK_jolla_> ouch +1
09:57:23 <cybette> #info this will be available earliest in autumn as mentioned earlier
09:57:35 <iekku> thanks cybette
09:57:46 <cybette> iekku: anytime :)
09:58:05 <thp> once that is in, though, we have a much easier way of adding new allowed APIs with every system update
09:58:06 <chriadam> why do people use seasons?
09:58:18 <chriadam> they're different everywhere
09:58:28 <M4rtinK_jolla_> well, sure
09:58:29 <tbr> it's a local thing...
09:58:51 <chriadam> as a way to represent a timeline / agenda, they're completely confusing IMO
09:58:53 <tbr> up here north it's more like "day" and "night" (exaggerating)
09:58:56 <cybette> let's revisit this in "autumn"
09:59:04 <cybette> and take the seasons discussion somewhere else :)
09:59:07 <M4rtinK_jolla_> but it still feels kinda late considering how many apps this is blocking from the main distribution channel...
09:59:07 <cybette> moving on
09:59:24 <cybette> #topic SailfishOS open source lisensed sources, update by tbr (5 min)
09:59:26 <thp> M4rtinK_jolla_: i agree. i am myself waiting for some APIs to push apps to harbour
09:59:33 <cybette> tbr: please go ahead :)
09:59:42 <tbr> Note that there are non-#info statements interspersed. Those are INTENTIONAL.
09:59:45 <tbr> #info Sources (OSS licensed) of SailfishOS are now again available for download. (There was some server downtime due to physical move.)
09:59:48 <tbr> #info The proper URL to the sources is http://images.formeego.org/jolla/sources/
09:59:51 <tbr> Right now that URL doesn't work yet everywhere, as DNS is back online for the domain since 20min. Will stabilize during the rest of the day by itself.
09:59:54 <tbr> #info Stskeeps and Jope are so kind to directly provide the release ISOs and tarballs to that server.
09:59:57 <tbr> That means we don't necesarily have to go through the whole cycle of requesting DVD by snail mail, them sending me a DVD, me uploading a DVD.
10:00:00 <tbr> #info The code drops are provided by Jolla as is.
10:00:03 <tbr> #info Currently Available are the source drops for: 1.0.0.5; 1.0.1.10; 1.0.2.5; 1.0.3.8; 1.0.4.20 (other sources are due very soon)
10:00:06 <tbr> #info Would it be interesting to process the data from those drops to track changes etc? Most of those link to git repositories.
10:00:09 <tbr> #info If there is interest, then this needs several helping hands to happen. Please contact me (tbr) on IRC.
10:00:12 <tbr> #info Jolla is kindly requested to independently provide MD5 or SHA1 hashes for the files, so that people can independently verify their provenance. (e.g. by posting on dev ML or TJC or twitter or signing the hash with a known Jolla key)
10:00:16 <tbr> That's it in a nutshell
10:00:18 <tbr> Stskeeps is currently working on update 5 drop
10:00:23 <tbr> Jope, you wanted to add something?
10:00:25 <Jope> yeah.. I'm uploading tar.bz2s of the isos in there now
10:00:38 <tbr> Also I welcome discussion about what to do with this
10:00:39 <Jope> and after that's done, I'll post the md5sums to devel@lists.sailfishos.org to make it "official"
10:00:46 <tbr> \o/
10:00:56 <Jope> and as tbr's notes said, the rest are coming soon :_)
10:01:14 <Jope> it takes a while to churn out the tarballs
10:01:23 <Jope> thankfully we made the computer work for us. :-)
10:01:38 <Jope> nothing else from me :-)
10:02:02 <tbr> I'm wondering if the community shouldn't use this and build at least a reference of open source components used etc
10:02:18 <tbr> The best thing that exists so far are Stskeeps slides and dependency diagrams
10:02:39 <tbr> I'm thinking of a list of packages, links to upstream and mer/nemo specific git repositories, etc
10:02:55 <tbr> as this was not an announced topic I don't expect much discussion now
10:03:08 <tbr> but would be glad if people would approach me afterwards
10:03:58 <tbr> cybette: I guess we can close the topic.
10:04:01 <cybette> yes let's have discussions after the meeting and feel free to bring it as a discussion topic in future meetings
10:04:05 <cybette> tbr: ok, thanks
10:04:17 <cybette> #topic Wrap up and next meeting (5 min)
10:04:59 <cybette> #info Sailors are starting to go on their vacations soon, proposal to have less frequent meetings in July/August
10:05:25 <tbr> what's "less frequent"?
10:05:31 <tbr> 2 weeks? 3 weeks?
10:05:39 <cybette> so far there's 2 votes for monthly http://piratepad.net/SailfishOSSMeetings
10:05:39 <tbr> not at all?
10:06:13 <cybette> let's take 2 minutes and vote in the pirate pad
10:06:30 <cybette> #link http://piratepad.net/SailfishOSSMeetings
10:06:57 <cybette> 4 vs 4!
10:07:10 <tbr> c'mooooon people! biweekly! biweekly!
10:07:14 <tbr> we can have them shorter
10:07:18 <cybette> (fortnightly vs monthly)
10:07:27 <iekku> who has 2 votes?
10:07:32 <tbr> but I think keeping them going is good
10:07:48 <sledges> there wasn't a meeting last week ;)
10:07:57 <lbt> iekku: don't know what you mean
10:08:01 <cybette> how about this, let's have the next one in two weeks, if turnout is good/normal like this, we keep that
10:08:10 <thp> cybette: +1
10:08:12 <sledges> +1
10:08:13 <tbr> WFM
10:08:32 <iekku> cybette, +1
10:08:32 <cybette> do we swap to 15:00 UTC?
10:08:41 * tbr doesn't care
10:08:49 <iekku> and can we have someone else as a chair
10:08:53 <iekku> no offence to cybette
10:09:01 * tbr can probably chair
10:09:11 <cybette> thanks iekku and tbr!
10:09:20 <iekku> tbr, <3
10:09:27 * tbr hugs iekku
10:09:31 <cybette> so tuesday 8th July at 15 UTC
10:09:51 <cybette> #info Next meeting Tues July-8 @ 15:00 UTC, Chairperson tbr
10:10:05 * tbr puts 2014-07-08T15:00z in his calendar
10:10:18 <cybette> thanks everyone, I think it's a wrap
10:10:32 <tbr> thanks admiral cybette
10:10:34 <cybette> see you in 2 weeks
10:10:37 <cybette> #endmeeting