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