[genivi-dlt] Patch moving dlt-daemon from FIFO to UDS (was: Issues with mechanism to change log-level)

Andersson, Gunnar gunnar.x.andersson at volvocars.com
Wed Oct 5 09:38:40 EDT 2016

Quoting might be wrong...

>On Wed, Oct 5, 2016 at 4:49 AM, Tobias Olausson <tobias.olausson at pelagicore.com> wrote:
>On 5 October 2016 at 07:17, Lipka, Christoph (ADITJ/SWG) <clipka at jp.adit-jv.com> wrote:
>Hi Tobias,
>>>I am interested to try your patch in the mentioned container scenario.
>>>Could you guide me to have a minimal demo setup I can test your patch?
>>Currently, no. The setup we have is rather large (LXC based containers),
>>but we are working on creating something smaller where we can test this
>>properly. This is a priority issue for us, so we will definitely work on
>>getting it fixed.
>>>Btw: We are currently merging the patch on top of current master to get
>>>a feeling how the daemon might look like and behave. It would be great
>>>if you can also have a look on the patch later.
>>I would be happy to!
>>>@Jeremiah: Might it be possible to handle this as pull request for
>>>community review in github? I anyhow don’t really like the current
>>>approach of sending patches to mailing list, since nearly nobody is
>>>checking patches or gives comments.
>>I agree, plus it gives much better opportunities to track changes +
>>discussion together.
>Absolutely. Let's set up a workflow that works for you folks. :-)
>For clarity, what do we want to set up? 

I think the poster just want your blessing for using PRs instead
of patches mailed to list...

Where is the "standard" patch submission policy documented, Jeremiah?
Maybe we just double check that it provides good default recommendations
but allows for flexibility according to maintainers?

>Pull requests for DLT daemon are
>available here: https://github.com/GENIVI/dlt-daemon/pulls I guess Tobias
>will have to clone DLT daemon and create a pull request, no? If we do
>that, shouldn't we take the opportunity to create a new branch? 
>We tend to always use the 'master' branch in GENIVI and that can cause
>problems sometimes.

Although...each PR is its own branch already, logically speaking.
You can even pull it from GitHub as a branch.

> Perhaps we start a dev branch or similar?

For what it's worth, a limitation in the GoCD plugin we use for automated
PR builds means it can only monitor PRs that are provided to master.
It sucks, but the bug seems open and my skills in understanding GoCD internals
are not up to snuff [1]

It's only a concern if we intend to automate building of PRs for that particular
project in go.genivi.org (which of course I recommend, unless you have 
something else set up that everyone can see)

DLT-daemon is being built on go.genivi.org now, since it will be included in 
the software dev environment.

>Also, here is the code for the softwarecontainer:

[1] https://github.com/ashwanthkumar/gocd-build-github-pull-requests/issues/66 


More information about the genivi-diagnostic-log-and-trace mailing list