<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 08/16/2016 09:04 AM, Lennart Poettering wrote: <blockquote cite="mid:20160816090456.GA3055@gardel-login" type="cite"> <pre wrap="">On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (<a class="moz-txt-link-abbreviated" href="mailto:johannbg@gmail.com">johannbg@gmail.com</a>) wrote: Johann, what you are posting here is really not helpful in any way.</pre> </blockquote> It's helpful in that way of letting people know that you have chosen to deviating from upstream first is policy so people can submit work which has not been accepted in other upstreams. Recent case in point is the that the wireguard maintainer was/is interested seeing it property integrated into systemd. Anywork related to that could not be started *until* he had his stuff merged in the upstream kernel however now anyone can have anything not upstreamed implemented in systemd. <blockquote cite="mid:20160816090456.GA3055@gardel-login" type="cite"> <pre wrap=""> Yes, we generally want a clear upstreaming perspective for kernel changes we support. But we have merged support for stuff that wasn't upstream yet before (most prominently: kdbus), and we will continue to do so in future. Yes, it would be great if cgroupvs2 would be fully merged in the upstream kernel, but given that in most parts it actually is and it provides systemd with major benefits to its core, I think it's fine to merge the support for cgroupsv2 already. </pre> </blockquote> Yes kdbus is a good example why this should not be done. Why not just have an experimental repository for out of tree, un-merged stuff upstream and those that want to use/rely/test that stuff can build and run it downstream? JBG </body> </html>