09:00:04 <sledges> #startmeeting Sailfish OS, open source, collaboration FOSDEM special - 7th February 2019 09:00:04 <merbot> Meeting started Thu Feb 7 09:00:04 2019 UTC. The chair is sledges. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:00:04 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 09:00:07 <sledges> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-February/008537.html 09:00:11 <sledges> I am the meeting's chairperson today filling in for James who's got a man flu :/ and will be doing my best to keep time and order. Please behave, respect the timings and be-have:) 09:00:25 <sledges> As we have many topics today (and even couple more left for next time), we'll keep time short for discussed and trivial ones 09:00:37 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with # info 09:01:06 <sledges> #info Simonas Leleiva - privateer @ Jolla 09:01:27 <chriadam> #info Chris Adams, developer at Jolla 09:01:37 <richrboo> #info Richard Booth - community 09:01:37 <ViGe> #info Ville Nummela - sailor @ Jolla 09:01:41 <flypig> #info David Llewellyn-Jones, sailor @ Jolla 09:01:50 <Thaodan> #info Björn - community dev 09:01:55 <dcaliste> #info Damien Caliste, community 09:02:04 <r0kk3rz> #info Lewis Rockliffe - community 09:02:45 <vknecht> #info Vincent Knecht - community 09:02:51 <pketo> #info Pami Ketolainen - sailor @ Jolla 09:04:50 <abranson> #info Andrew Branson - sailor who was at fosdem 09:05:22 <sledges> alrighty let's get goin'! 09:05:30 <sledges> #topic Qt 5.9 upgrade (asked by DylanVanAssche - 5 min) 09:05:36 <sledges> #info What's the status of the Qt 5.9 upgrade? Qt 5.9 is definitely needed to be able to move forward with SFOS app development. We know that Jolla is working on it, but what are the main blockers that block the Qt upgrade? 09:05:40 <sledges> #info When Qt 5.9 is introduced in SFOS 3, we can finally try to tackle the QtWebengine situation with Jolla. 09:05:52 <sledges> #info Answer from veskuh (during FOSDEM): 09:06:00 <sledges> #info Two things for releasing Qt 5.9: first is the licensing change to GPLv3 that we need to receive an OK from our partners, or take the commercial licence path instead. 09:06:15 <sledges> #info Secondly, it's the technical part, that you might have seen residing in our developers' branches, that still requires more polishing. It also needs to have a window for dedicated release for a complete regression testing. 09:06:26 <sledges> #info We are looking reasonably into the summer or even 2nd half of 2019 for the Qt 5.9 roll-out. 09:07:04 <r0kk3rz> just do it already :P 09:08:04 <Karry> #info Lukas - community dev 09:08:33 <dcaliste> If partners agree to ship Qt under GPLv3, would that apply for other projects, like GnuPG for instance ? 09:08:51 <dcaliste> That would be a _huge_ news ! 09:09:06 <sledges> if Qt is OKd for GPLv3, then there will be additional decision making for other projects to go GPLv3, or stay at GPLv2 (Qt being the exception) 09:09:37 <kimmoli> #info Kimmo Lindholm - community 09:09:51 <r0kk3rz> deja vu ;) 09:10:04 <dcaliste> Ah, was afraid of this :/ So far so good, will live with it. 09:10:53 <sledges> there was an anti-tivoisation modifier clause that can get negotiated in an altered GPLv3 if i understood fosdem discussion correctly (Thaodan was the one mentioning), but that's a topic for next time:) 09:11:18 <Thaodan> sledges: yes maybe ask the FSF(E) on that. 09:11:47 <sledges> Thaodan: any more keywords to throw in? :) was it some ~eGPLv3p ? :) 09:11:53 <r0kk3rz> wouldn't you need to negotiate with every single project on that? 09:12:19 <Thaodan> no idea just heard in a talk with linus torwalds 09:12:34 <sledges> ok, thanks, will keep it in a back of our head:);) 09:12:39 <Thaodan> r0kk3rz: I think so. 09:12:43 <sledges> moving on, time's <precious> 09:12:49 <sledges> #topic Community's help with the Browser engine upgrade (DylanVanAssche - 15 min) 09:12:53 <sledges> #info Community would like to help with any Browser upgrade work; thus having instructions on how to build all needed components and test on their devices would be highly appreciated (e.g. on SFOS wiki, quick'n'dirty is better than none :) 09:12:57 <sledges> #info Can Mer OBS be used? Can all associated packages be backported from devel (master) to build against the current release (3.0.1) ? 09:13:04 <Thaodan> sledges: give me the ring! 09:13:08 <sledges> #info Answer from rainemak: all the work is in public: 09:13:25 * sledges calls Thaodan 09:13:25 <sledges> #info We cannot always guarantee that builds / runs agains the current release but normally that's the case. 09:13:31 <sledges> #info Browser engine related components can build in platform sdk: xulrunner-qt5, qtmozembed-qt5, embedlite-components-qt5, and sailfish-components-webview 09:13:39 <sledges> #info Sailfish Browser application can be built in application sdk (please take the instructions below with a grain of salt) => Platform SDK works for sure for browser app as well 09:13:49 <sledges> #link https://github.com/sailfishos/sailfish-browser/wiki/BuildingInstructions 09:14:06 <sledges> #info Further, there will be a browser update coming later this spring but you can already help there if you like. Ask rainemak for more instructions if/when needed, he'll try to help. 09:14:12 <r0kk3rz> maybe i should try plugging it into obs 09:14:27 <sledges> plug it already ;P 09:15:55 <sledges> #info situ has a reasonably well built project: 09:15:59 <sledges> #link https://build.merproject.org/project/show/home:siteshwar:branches:nemo:devel:mw 09:16:10 <Thaodan> side questions can have a way to enable/disable text prediction in webview ? no need to answer just take notice 09:16:11 <sledges> just needs bumbing some versions 09:17:06 <abranson> obs is definitely the best way to build that 09:18:19 <sledges> Thaodan: text prediction works within webpages (inside text input boxes which are not passwords). To enter a URL i believe it was disabled intentionally, for dictionary not to learn many non-words et al. :} 09:18:45 <Thaodan> sledges: only the sailfish browser. Not in webview 09:19:21 <Thaodan> https://github.com/llelectronics/webcat/issues/61 09:19:47 <leszek> webview is qtwebview. Afaik jolla abandoned all development on it. At least for 2 years no one reacted on my PR 09:20:31 <leszek> It is highly not recommend to run webcat with jollas stoneage qtwebkit build anymore as it puts you in high security risk mode 09:20:41 <Thaodan> can we test the browser update in a way that risiki users can try the update without harm? 09:20:42 <sledges> if it's the exact same used in the Email app, can be tested by sending an email with input box? :D 09:20:42 <leszek> there are countless of security wholes in it 09:20:47 <leszek> -w 09:21:31 <leszek> sledges: it is the same. Thats the reason I don't even touch the email app anymore. With such an outdated qtwebkit it is too risky 09:21:35 <Thaodan> sledges: it is but we cant detect which field is used or say no text prediction for passwort fields 09:23:02 <sledges> Thaodan: if a seasoned developer builds the newer browser and sanity-tests it, it can be given to other users to update from an OBS repo `ssu ar newbrowsengin <obs_repo_url>` and version --dup, if a developer gotten version numbers right, but there may be dragons, we won't know until we try 09:26:15 <sledges> moving on in 1 09:26:21 <vknecht> what about overriding bookmarks.json from sailfish-content-browser-default ? any supported way to do it ? 09:26:25 <leszek> apros pros browser engine upgrade from the topic. Which browser engine is meant? If its the jokabel jump from Gecko 38.8 to 45.something than I don't even want to support this. The only upgrade would be the move to QtWebEngine 09:26:55 <r0kk3rz> yeah bump to gecko45 09:26:58 <vknecht> (sparse & Provides: sailfish-content-browser-default didn't work) 09:27:00 <leszek> and I would highly recommend any community + dev member not working with Jolla on that topic 09:27:11 <r0kk3rz> i think its meant as an interim, because things are pretty bad at the moment 09:27:16 <leszek> gecko45 is outdated and unsecure 09:27:37 <leszek> We as community should not support such things 09:28:06 <chriadam> QtWebEngine requires Qt5.9 upgrade AIUI 09:28:13 <leszek> It is wasted energy and time that could be spend better in bringing a up to date browser engine to the platform 09:28:26 <leszek> chriadam: qtwebengine exists for qt5.6 aswell since years 09:29:24 <leszek> even Qt5.9 qtwebengine is based on an slightly outdated blink engine. But granted Qt5.9 is needed for bringing newer blink engine based QtWebEngine builds 09:29:24 <r0kk3rz> afaiu half the work was already done a while ago, so quickest path is to finish it 09:29:55 <sledges> #link https://git.merproject.org/mer-core/gecko-dev/commits/esr45 09:30:07 <leszek> r0kk3rz: you mean gecko45? Yeah saw it being in development since a few years. If you want to finish this do it. But without any support from the community 09:30:24 <sledges> next topic is somewhat related, moving towards 09:30:24 <leszek> its wasted time imho 09:30:28 <sledges> #topic Ask Mozilla "Firefox for Android" developers to ease future Browser updates (asked by someone at FOSDEM - 5 min) 09:30:36 <sledges> #info There exists a trusted possibility to encourage the Firefox for Android developers to proceed with decoupling the latest gecko-u (IIRC) engine from the androidy bits, in order for SFOS to be easier to upgrade up to quite a high version. 09:30:50 <sledges> #info Would Jolla want to explore this path, as mid- or long-term plan? 09:31:04 <sledges> #info Answer from rainemak: We're evaluating our browser strategy. This could be an interesting way but cannot promise yet. 09:31:45 <Thaodan> maybe ask first if there's a way to seperate the java bits and allow different guis 09:31:56 <leszek> Highly doubt Mozilla folks are aware of the existence of SailfishOS. Even if they are they simply won't invest time. That is the sad truth. Would be something different if Jolla as a company would aim for a cooperation of some sorts (which needs money that jolla most probably does not have) 09:32:13 <sledges> as far as I understood, such decoupling has already been tried and waiting for more traction 09:32:36 <Thaodan> leszek: that doesn't really depend on jolla. More on different plattforms than android 09:32:44 <Thaodan> *other thab 09:32:46 <Thaodan> *than 09:33:01 <leszek> But true for now Jolla fucked up the browser situation on SailfishOS. If someone else can be paid to fix it it can't be worse 09:34:10 <r0kk3rz> its really up to mozilla if they want to take embedding api seriously 09:34:47 <sledges> the topic was raise by a person with connections i'm sure, otherwise it would not be just like that out of the blue 09:35:43 <r0kk3rz> in the past ive spoken with MZ people who agreed that gecko should have an embedding api, but so far it hasnt happened 09:35:49 <sledges> so currently just gauging interest 09:35:59 <sledges> time's up for this one 09:36:02 <sledges> #topic OpenSSL update before EOL (asked by someone at FOSDEM - 5 min) 09:36:06 <sledges> #info 2019 is the last year for OpenSSL 1.0.2, does Jolla have plans to transition to 1.1.1 ? 09:36:13 <sledges> #info Answer from Jolla: A branch has been prepared for this, but our partners weren't ready for it at the time. We will switch to it when they are. 09:37:02 <sledges> i guess there's nothing much to say, i'll move on in cpl'o'minutes 09:38:32 <sledges> #topic Why are you using older geoclue than version 2 ? (Zeeshan Ali - 5 min) 09:38:41 <sledges> #info Zeeshan Ali geoclue maintainer showed up in person and asked: is there any reason why Jolla started with an old geoclue? 09:38:50 <sledges> #info geoclue2 has been around for a while and has MLSDB integrated, as well as other goodies. Would there be plans to move to version 2? 09:39:06 <sledges> #info Answer from sailor1: Not 100% sure, but most likely the QtMobility geoclue plugin (from 2009 or so) was written against original geoclue, so we just kept using that. Since then, we haven't had resources to spend on things which are already working well enough. It'd be nice if we could. 09:39:19 <sledges> #info Answer from sailor2: Geoclue 2 is more monolithic system, whereas we need to have the specific backend services splitted out. 09:40:33 <leszek> anymore topics? 09:40:42 <sledges> #topic Helping with the PIM (personal information management) stack (asked by Karry - 10 min) 09:40:53 <sledges> #info A developer would like to improve/contribute to the PIM SFOS stack. Which packages should be looked into, what is the state of SFOS utilising the QtPIM module? 09:41:48 <sledges> #info Answer from sledges: QtPIM status can be found in the wiki: 09:41:49 <leszek> this is related to the browser engine talk aswell. Just to repeat here. The E-Mail client is unsecure by default as long as it uses the old qtwebkit version 09:41:53 <sledges> #link https://sailfishos.org/wiki/index.php?title=Special%3ASearch&search=QtPIM&go=Go 09:42:28 <sledges> #info Answer from Chris: Community member Alberto Mardigan (mardy) is looking into helping us with this too, and we have definite plans to start investing engineering effort in this area in the nearish future 09:42:41 <sledges> #info Answer from jpetrell: please contact jpetrell on Freenode. we can potentially sign a contract, giving access to internal PIM repositories to help develop the end-to-end PIM stack. 09:43:18 <chriadam> if you have questions about repositories etc, ping me also. can point you in the right direction etc. but yes we have definite plans here. most of it is opensource. 09:44:01 <sledges> this mostly involves contacts and calendar 09:44:28 <sledges> Karry: good to see you joined, was nice to connect at FOSDEM 09:45:02 <sledges> #info chriadam: if you have questions about repositories etc, ping me also. can point you in the right direction etc. but yes we have definite plans here. most of it is opensource. 09:45:23 <chriadam> Karry: I don't know how much specific info I can give, but broadly speaking: we have plans to update QtPIM to latest version, requires fixing the backend to support the updated addressbook semantics, and then updating other middleware libs (like nemo-qml-plugin-contacts) and sync plugins. 09:45:31 <Karry> great to hear that transition to QtPIM is in the stack 09:45:54 <chriadam> on the calendar side, my personal opinion is that I'd like to shift to using QtOrganizer since kcalcore/mkcal are old and we are the defacto maintainers of mkcal... but resourcing etc might preclude that. 09:46:39 <dcaliste> chriadam: we may resume some regular meeting on calendar things, to plan together the transition to QtOrganizer, planify tasks… 09:46:43 <sledges> AFAIU we already use QtPIM, but later versions would also require newer Qt(?) 09:47:05 <Thaodan> chriadam: isn't there kf5 kcalcore=? 09:47:09 <chriadam> no, QtPIM is still LGPLv2.1 IIRC. 09:47:13 <chriadam> Thaodan: kcalcore yes, not mkcal 09:47:34 <chriadam> and our kcalcore lib is old. updating would be quite some work, probably require backend changes (and at that point, what do we gain?) 09:47:49 <chriadam> well, I haven't studied it in detail, haven't had time. 09:47:56 <abranson> migration would be needed too... 09:48:04 <Thaodan> chriadam: whats the replacement for mkcal= 09:48:05 <Thaodan> *? 09:48:57 <chriadam> Thaodan: two options that I can see (again this isn't official Jolla position, just my opinion): 1) use mkcal internally as a storage backend for QtOrganizer, but use QtOrganizer API in stack etc. 2) write an sqlite-backed QtOrganizer-specific backend 09:49:32 <Thaodan> chriadam: ah thats were Korginizer uses Akonadi? 09:50:31 <chriadam> Thaodan: again I might be wrong, but I think Akonadi is a plugin-based domain-agnostic storage backend, so it must have some "calendar-specific" plugin. not sure what it's based on, might be kcalcore. 09:50:46 <dcaliste> chriadam: well mkcal is well written IMHO and is defacto a sqlite backend for calendar events, the bad points being the fact that it's linked to kcalcore that has some restrictions like all events in the same table with unique IDs while not separated into notebooks… 09:51:11 <chriadam> dcaliste: and doesn't support some things like sync anchors properly, nor some timestamp semantics 09:51:35 <chriadam> is it well written? I haven't delved into it deeply, but I've hit its limitations a few times :-/ 09:51:44 <dcaliste> Yes, that's right, but rewriting a full sqlite backend would be a huge work… 09:51:51 <chriadam> yes 09:51:54 <chriadam> I have to agree there 09:52:04 <Thaodan> chriadam: I know but is still its storage backend whatever it does afterards 09:52:11 <pvuorela> not sure i'd call that well-written. 09:52:19 <dcaliste> The implementation looks nice and is easy to read, but it's limited by limitation from kcalcore I think. 09:52:43 <sledges> we're over time, maybe chriadam you could say the time of your next meeting with dcaliste on #sailfishos for others to chip in? 09:52:58 <dcaliste> pvuorela, well when reading it, I understand what it's doing. kcalcore is less clear in my opinion. 09:53:20 <dcaliste> from the bits I've dwelved into at least. 09:53:24 <chriadam> dcaliste has a schedule clash as I understand it, so isn't at the meeting this coming Tuesday, but will be again the Tuesday after (is that correct?) 09:53:40 <abranson> a new sqlite backend would still leave us as sole maintainers. aren't there any others out there we could use? 09:54:01 <dcaliste> abranson: very good point ! 09:54:17 <abranson> but i guess it could be a lot less complex 09:54:23 <Thaodan> abranson: follow KDE ? They'll do similar things for plasma mobile 09:54:28 <dcaliste> sledges: yes we can schedule a specific meeting for this later on. I'm off next week though, but will be ok the week after. 09:54:32 <chriadam> you know my mantra. reduce external dependencies ;-) 09:54:50 <chriadam> but that's why everything I've said is personal opinion and not Jolla position :-) 09:55:18 <abranson> Thaodan: yes, you'd think all these mobile linux projects using Qt would need similar backends for this stuff 09:55:47 <abranson> chriadam: i do understand, but at the same time things like the browser show how becoming the maintainer of something large can be extremely painful 09:55:47 <sledges> #info ping chriadam for to know the time of the cal/card Tuesdays meeting in a fortnight in #sailfishos for more discussion 09:55:54 <Thaodan> yes why not? that was the reason for akonadi. Despite its outcomwe 09:56:09 <Thaodan> maybe ask at #kontact or #akonadi 09:56:11 <chriadam> abranson: browser is IMO different. data storage is "do it once, hopefully properly, then don't touch it ever again" (IMO). 09:56:30 <sledges> time to move on lads:) 09:56:35 <abranson> then we might as well just fix mkcal... 09:56:51 <sledges> #topic Mer -> Sailfish OS merge (summarised by sledges - 15 min) 09:56:51 <chriadam> but then we have random API inconsistency that I mentioned. 09:57:12 * lbt is around but forgot to #info :) 09:57:15 <sledges> #info As said by lbt last time, Mer is being renamed to the Sailfish OS opensource core. A short summary of what has been discussed during FOSDEM: 09:57:32 <sledges> #info Community would prefer to have a Sailfish OS bugzilla for seasoned developers to chip in and also report bugs (TJC is for end-users). Jolla already has linking+cloning instrumentation from the internal Bugzilla to both, and moving to GitLab or Phabricator would involve too much risky effort. 09:57:47 <sledges> #info We also have a plan to make JB# (and any other bug-refs) less evident in the git commits. 09:58:07 <sledges> #info As per other Mer services: 09:58:16 <sledges> #info Markup documentation under Git would be preferred over a read-write SFOS wiki due to a better review process. 09:58:22 <leszek> its a nice move definitely for all the critics about SailfishOS not being opensource. Now you can show them in da face. It is :P 09:58:32 <sledges> #info OBS is being used by porters and potentially helpers of browser engine upgrade, hence would also be welcome to have an OBS after the merge. 09:58:46 <sledges> #info Mer Imager is not being used, r0kk3rz' https://gitlab.com/sailfishos-porters-ci is finely fit for purpose. 09:58:55 <sledges> #link https://gitlab.com/sailfishos-porters-ci 09:59:02 <sledges> #info The "chum" repos on Mer OBS (openrepos alternative) is not being used, although it would be nice to see OSS harbour apps building on OBS before they directly go to the Shop. 09:59:17 <Thaodan> I hope bug REFS#num stay but with bug repotts that the community can use. 09:59:18 <sledges> that's the end of recap, lbt have you got us moar? :D 09:59:38 <lbt> leszek: I don't want to mislead - this is not about the code, it's more about combining the Mer Project and Sailfish communities to make the whole thing a clearer community base for SFOS 09:59:43 <sledges> Thaodan: they will all stay, but should be hiding inside commit body, not subject line 10:00:20 <Thaodan> ok thats much better commits lines where much to long and broke 10:00:22 <sledges> we still must have the [tag] Message. BUG#ref line in every relevant commit for CI purposes 10:00:41 <chriadam> lbt: and hopefully smooth the process to opensourcing currently closed parts of SFOS, in the future? given that there is clear infrastructure and branding and bugtracking etc 10:01:00 <leszek> lbt: its the first step to a sailfishos core version that can work without the proprietary bits and blobs. I wonder if someone would take the chance to write a wrapper for those few cpp libs of silica to make it fully open 10:01:01 <sledges> but [tag] is being eaten away by git format-patch -> git am if it's in the subject ;) 10:01:31 <dcaliste> sledges, moving the JB id inside the body from the summary won't help knowing about the disucssions behind a JB# thing though… 10:01:37 <lbt> The only other thing to discuss is that today we have 2 ldap systems - Mer and SFOS (actually accounts.jolla.com ) and we'll be using accounts.j.c in the future 10:02:02 <sledges> dcaliste: if a bug is dealt with, a properly formulated commit subject+body should suffice 10:02:07 <chriadam> lbt: will that change to accounts.sailfishos.org or? 10:02:12 <lbt> chriadam: this makes it totally obvious that git.sailfishos.org is where the open source lives 10:02:18 <lbt> and it should have as much as possible 10:02:26 <sledges> dcaliste: it's not ideal, but we want sailors' braindumps to end up as SF# so community can pick up 10:02:42 <chriadam> lbt: great. we have some github stuff at the moment still (e.g. silica-webview, some hybris stuff) will that all move to git.sfos.org? 10:02:44 <lbt> chriadam: No. That stays as a jolla managed system 10:02:46 <chriadam> ok 10:02:52 <sledges> other JB# are confidential or intertwined with non-oss, but we'll try to keep them low in numbers for oss components 10:02:56 <abranson> chriadam: and it'd be nice to see the nemo glacier etc on there, so a fully foss build is possible even now 10:03:08 <lbt> I would encourage all clearly distributable source to move to g.s.o 10:03:13 <chriadam> amen 10:03:19 <dcaliste> sledges, I agree, just noticing that JB# are often used in open source parts also. 10:03:32 <lbt> I think there may be issues wrt hybris and some bits... not sure there 10:03:49 <chriadam> dcaliste: it's definitely a problem, we need to resolve somehow 10:04:09 <sledges> dcaliste: all what i said above applies to JB# appearing in open parts 10:04:25 <dcaliste> I'm complaining, but I understand it's a mess to handle two bugzillas for the developers. 10:04:31 <lbt> leszek: I think that's what nemo was - but they have moved away afaiui 10:05:00 <lbt> dcaliste: it's not impossible to have 2 BZs 10:05:37 <lbt> we have a *lot* of expertise in BZ internals ... eh pketo? 10:05:40 <leszek> lbt: they wanted to mimic the Meego N9 UI afaik 10:06:17 <leszek> having silica open even if just a subset would be really nice. 10:06:34 <lbt> I agree - but it's not part of this sadly :/ 10:06:56 <lbt> I hope that more involvement and community growth will drive us to open silica 10:07:09 <sledges> amen to that too 10:07:12 <lbt> putting silica into mer was always a bit of an odd fit 10:07:21 <abranson> after seeing so many 'mobile linux' projects at fosdem, and none of them seeing sfos as one of them, I think that having a fully foss build is something we should urgently have. 10:07:31 <lbt> we can now shout "But this is sailfishos.org... silica belongs here" 10:07:44 <dcaliste> lbt: sure, but routine would tend to using mainly only one BZ over the other one. As it happens now with mer BZ and internal JB. While JB is still need for confidential purposes… Complicated. 10:07:45 <leszek> abranson: full ack 10:08:05 <dcaliste> abranson: so true. 10:08:24 <pketo> lbt: yeah, it's not impossible, but complicated in many cases 10:08:25 <lbt> dcaliste: that is true 10:08:30 <sledges> dcaliste: + for hours tracking, project trees, blockers, you-name-it:) 10:09:01 <M4rtinK_phone_> at Red Hat we have a single Bugzilla instance for RHEL and Fedora, including private RHEL bugs 10:09:35 <dcaliste> Would a BZ exists that can restrict filter bug view depending on on logged people? 10:09:53 <M4rtinK_phone_> so it is doable & helps a lot as many bugs impact both, need to be backported etc. 10:09:58 <dcaliste> M4rtinK_phone_: yes something like that. 10:10:12 <dcaliste> So only one BZ but different usage, views… 10:10:17 <abranson> yeah but it's risky. there a lot lower chance of accidentally leaking confidential info if the trackers are separate 10:10:29 <lbt> M4rtinK_phone_: I'd question if we could take an existing bz which has been "known to be internal" and open it up without serious risk of exposing confidential information. 10:10:36 <dcaliste> that's true. 10:10:44 <M4rtinK_phone_> dcaliste: that's how it works, there are groups and bug acces is based on group membership 10:11:27 <M4rtinK_phone_> lbt: then start with a public one and start adding/importing private bugs 10:11:33 <abranson> also the churn on a public bugtracker is a lot higher than a private one. duplicates get filed more often, wrong areas assigned. 10:11:45 <abranson> it can make a mess for reporting tools etc 10:12:24 <lbt> I think developing a public bz and working on it as much as possible and then syncing data to an internal one would make most sense 10:12:53 <Thaodan> abranson: if it works for Red Hat why not for Jolla? 10:12:54 <lbt> the truth is that whilst we commit in the open we don't work there 10:13:03 <lbt> we certainly don't plan there 10:13:15 <M4rtinK_phone_> bugzilla.redhat.com hosts 4+ RHEL releases, all Fedora bugs and even many related upstream projects (DNF) 10:13:37 <M4rtinK_phone_> it works & would be a disaster if we had two trackers 10:13:41 <chriadam> Thaodan: because Red Hat have enormous budget, and can probably afford to hire multiple people whose job it is to just manage the bugzilla instance. 10:13:50 <lbt> +1 10:13:52 <abranson> yup 10:14:17 <M4rtinK_phone_> also there are even customer groups 10:14:36 <Thaodan> chriadam: so its managing one instance or managing sync 10:15:08 <sledges> we'll move slowly to General discussion 10:15:10 <M4rtinK_phone_> you can grant acces to bugs per customer 10:15:21 <sledges> #topic General discussion (5 min) 10:15:23 <abranson> M4rtinK_phone_: we do this internally 10:16:06 <M4rtinK_phone_> also one more think - note how Sailfish and related project more and more merge together 10:16:08 <dcaliste> sledges: thank you for reporting all these discussions from FOSDEM for those not attending. 10:16:29 <sledges> dcaliste: my pleasure, the goal was achieved - even more ideas thrown together! 10:16:39 <r0kk3rz> was a good discussion at the time! 10:16:46 <sledges> we'll continue in two weeks with couple of SDK questions by Thaodan that didn't make it today 10:16:48 <abranson> but everyone should come to fosdem next year if they can! it's really quite amazing. 10:17:05 <M4rtinK_phone_> older RHEL and new Fedora can be pretty different and yet it is highly benefical to have bugs in one place to track stuff down 10:17:21 <Thaodan> did veskuh fix the recording? 10:17:28 <sledges> as well as ARM64 by locusf and QtGeolocation (but I'm forgetting exactly what was needed to be refined by both :") 10:17:32 <M4rtinK_phone_> in case of Sailfish OS there is not even two distros ! 10:18:02 <M4rtinK_phone_> so having two tracker makes no sense to me personally, really 10:18:04 <sledges> Thaodan: recording is superfluous now that we've summarised, and we'll keep on recapping after next two weeks + new community topics 10:18:27 <chriadam> one final point from me: I am personally very grateful to the community members who continue to be incredibly patient with us, and continue to work with us, on the opensource parts of the OS, to help improve it for everyone 10:18:42 <sledges> +1 \o/ 10:18:49 <chriadam> I know that things can seem "unmoving" at times, but there is lots of things going on in the background, and efforts from individual sailors and privateers to try to open up more, etc 10:20:07 <M4rtinK_phone_> chriadam: while there is really no Sailfh OS alternative yet it looks like some people are loosing patience a bit 10:20:14 <chriadam> entirely understandable 10:20:56 <sledges> speaking about lots of things going on, especially now that we got more sailors on board. 10:20:59 <M4rtinK_phone_> and especially the many dead native applications in especially Store and often Open Repos are really concerning 10:21:24 <chriadam> by dead, do you mean "broken by API changes"? 10:21:26 <Thaodan> until its to late and people switch. For example maemo leste got nemo wrong and did a dead horse fork 10:21:27 <sledges> M4rtinK_phone_: not forgetting aliendalvik is part of the culprit equation 10:21:52 <dcaliste> As abranson said, the main threat imho is that SFOS is not seen from outside with open source parts. That prevents other initiative to use SFOS solutions and give back improvements. 10:22:12 <leszek> M4rtinK_phone_: you cannot remove them. Otherwise people might've removed the dead stuff 10:22:16 <sledges> dcaliste: yep, and it used to be hard to adopt mer-core as such 10:22:40 <M4rtinK_phone_> chriadam: that & people giving up due to broken outdated libraries, stupid store policies and lack of docks 10:23:02 <sledges> as much as i like this chatter, it's time to wrap up, is lunch in Finland (and breakfast for me :D) 10:23:11 <abranson> Thaodan: yes, awareness of the nemo/mer/sfos relationship was really low at fosdem 10:23:16 <M4rtinK_phone_> *docs 10:23:31 <dcaliste> Many middleware in SFOS are great model-view separated implementations, it's a pity that they are not advertised and used in other platforms. 10:23:49 <eekkelund> abranson: as always.. :/ 10:23:55 <M4rtinK_phone_> I dont want to say "we said that" but we said that 10:24:09 <leszek> xD 10:24:13 <r0kk3rz> dcaliste: they are used in a few projects 10:24:16 <abranson> eekkelund: yep, hopefully this rebranding is a chance to correct that 10:24:19 <Thaodan> please no more forks. Its really sad to see 10:24:28 <M4rtinK_phone_> and its not just about OSS zealots, its even just being able to fix stuff yourself... 10:24:34 <eekkelund> abranson: hope so! 10:24:56 <sledges> the mainly bliss is that we have a most-productised non-Android Linux phone to-date with smoooth UI, receiving regular updates, and many of us don't need to carry two phones around! 10:25:05 <M4rtinK_phone_> not to mention sharing component development across mobile distros etc. 10:25:22 <chriadam> M4rtinK_phone_: we have trialled NDA for community members, and that was extremely successful. that bunch of code should be in (devel) repos early next week, related to email signature support. 10:25:26 <r0kk3rz> M4rtinK_phone_: not even the 'open' mobile systems are doing that :P 10:25:29 <chriadam> huge thanks to dcaliste for that 10:25:32 <M4rtinK_phone_> sledges: thats indeed true 10:25:52 <chriadam> the point is: for people who want to contribute to the closed-source core, there is potential to do so, via NDA, now. talk to jpetrell. as mentioned in the PIM discussion above. 10:25:55 <sledges> should use that to our advantage 10:26:10 <chriadam> M4rtinK_phone_: but I agree with your broad general point. again I would say: resources limit what we can do in what period of time. 10:26:33 <sledges> #topic Next meeting time & date (5 min) 10:26:37 <M4rtinK_phone_> chriadam: thats better than nothing I guess (though I know patches for this have been available for years, unmerhed...) 10:26:40 <chriadam> and we have to prioritise paid projects from internal customers. the key is to find where that aligns with OSS goals and promote those to our internal customers. 10:26:41 <leszek> chriadam: jolla needs one sailor to search for a chinese billionaire to finance Jolla 10:27:06 <r0kk3rz> they already have one? or they did at one point 10:27:11 <sledges> the next meeting on IRC will be held in fortnight on Thursday 21st of February at 09:00 UTC 10:27:12 <leszek> or in general a billionaire 10:27:16 <r0kk3rz> lately i think its russian billionares 10:27:16 <sledges> all those in favour 10:27:22 <r0kk3rz> sledges: +1 10:27:28 <chriadam> sledges: +1 10:27:32 <M4rtinK_phone_> ask Elon on Twitter ;-) 10:28:01 <sledges> #info the next meeting on IRC will be held on Thursday 21st of February at 09:00 UTC 10:28:03 <leszek> yeah maybe this. Tell him you will add a flamethrower app by default 10:28:14 <r0kk3rz> elon lol... 10:28:18 <sledges> many thanks y'all and let's keep on hackin'! 8D 10:28:20 <sledges> #endmeeting