Hello everyone,<div><br></div><div>There are a few interesting developments that should be shared.</div><div><br></div><div>Firstly, there are discussions about moving the -lowlatency kernel maintenance into the kernel team as it was pointed out that the patch is "something like a two line" patch.  I don't actually know how long our patch is.  And it seems disproportionate to have to rebuild a new kernel each time of a security update for such a patch.  It was suggested that this might become a build option for an existing kernel package maintained by UKT.</div>
<div><br></div><div>Initial discussion with UKT have been fairly positive.  They were reducing the number of kernel they maintained and it seems that this was contrary to their efforts, but it was also realized that the actual maintenance of this kernel would be minimal.  Queries also were presented about UKT's official maintenance and responsibility of the -lowlatency kernel.  I'm not sure this was answered directly but it appears that because the kernel would be built by UKT, it doesn't mean that Canonical or UKT would actually be required to support this kernel in an official capacity.</div>
<div><br></div><div>The next query was where the -lowlatency kernel would therefore be placed within the repository.  Currently it is in the Universe repository, but the existing kernel packages maintained by UKT are in Main.  Clean consensus was not reached because of ongoing discussion of archive reorganization.  I will be in a meeting this afternoon which will discuss the archive reorg so I should have more information later.</div>
<div><br></div><div>It should be clear that a final decision has not been reach, but from my perspective there doesn't appear to be any clear blockers at this point.  Therefore I remain hopeful that this will happen as it will greatly reduce the workload for the small number of active members.</div>
<div><br></div><div><br></div><div>Secondly, I hope to talk to some of the JuJu [0] people about the possibility that JuJu might help with Studio in any way.  My poor explanation is that JuJu is a simplified way to deploy and manage web applications in a scalable manner.  My hope is that we might find a way to help with automating application startup, settings, and connections (if applicable) for various work flows, not just audio.</div>
<div><br></div><div><br></div><div>Lastly, I hope to also talk with Gema [1], who is leading QA and automated testing I believe, about deploying automated testing for Studio.  My hope is to again, reduce the number of manual tasks we perform in order to support Studio.</div>
<div><br></div><div><br></div><div>Cheers,</div><div>ScottL</div><div><br></div><div>[0] <a href="https://juju.ubuntu.com/">https://juju.ubuntu.com/</a></div><div>[1] <a href="https://launchpad.net/~gema.gomez">https://launchpad.net/~gema.gomez</a></div>