Is the maintainer contact info up-to-date?

[jeremiah]

Is the file ../blob/master/MAINTAINERS.md current? Does the email address work?

[gunnarx]

Bump!

@jacky405 We've been working to adopt and recommend ivi-logging for GDP (and consequently recommend it for all C++ programs that want to interface with DLT).

You can see examples here that C++ wrappers are desired and other alternatives are apparently being applied by others. (That class seems to be taken from AudioManager by the way.)

It would be appropriate to know who to consider as maintainer, if we are going to continue to recommend this, or if we even want to move this to GENIVI GitHub.

---

FYI @frznlogic

[gunnarx]

Some GitHub magic caused "unassign" of jacky405 - which was not intended. --> @jacky405
Uh.. how can I unassign people in this repo anyway? It's on Pelagicore account and I'm not allowed to assign people. As I said, "magic".

[jeremiah]

I can take a look in our repo to see if I can fix that. That account may have been moved from Pelagicore's repo since Jacques had moved on. He still works with us though so I'll contact him to make sure he sees this if he hasn't already.

[gunnarx]

What I meant was that I did nothing active (that I know of) to make GitHub write this:
"gunnarx unassigned jacky405 5 hours ago"

I think it was just some magic - naybe when I added FYI @frznlogic to the end of the comment or something.

[jacky309]

Hi,
I have just discovered that message thread. Sorry for not reacting earlier.
I assume there has been something new regarding the adoption of ivi-logging in Genivi since October, so maybe you can provide an update ?

[gunnarx]

@jacky309 For GDP the status is mostly unchanged - we left it open with this question. The first inclusion of ivi-logging recipe was merged already before my question. Every software component does not use ivi-logging interface yet, but the basic intention has not changed. Whether it's worth modifying a particular component really is on a case-by-case basis, but the "policy" is there to move towards that, and to guide new component development.

For all GENIVI members systems, I have little information to share. IMHO GDP policy is what we need to agree on and move forward with.

The proposed "policy" for GDP was roughly:

1. Generic C++ programs - use ivi-logging abstraction, with DLT backend as default.
2. C++ programs that are also Qt programs - QDebug() seems preferred. Again, in GENIVI integrations, look at the bridge to DLT that exists there. (Someone was going to check the license there?)
3. C programs - use DLT directly. Another abstraction adds little value here.

Point #2 can likely be influenced by Pelagicore/Luxoft's opinion, but my understanding of your advice so far is to use QDebug().

So, Jeremiah's and my own question remains. Is the mail address correct and are you available if we start using this more actively. Shall we consider this repo the upstream, or would it make better sense for GENIVI to fork it when we start using it actively.

Future options might want to also consider syslog-ng