Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
Jóhann B. Guðmundsson schreef op 16-08-2016 18:58: I personally recommend the project should stick with the original line drew in the sand, for the master branch and all the "experimental" stuff which may or may not come to pass, be kept in it's own experimental branch which would be the best of the both worlds I would think. Downstream that want stability get what they want and are less likely to experience any sudden *surprises* and those that want the experimental stuff for whatever reason like testing get what they want. Not wanting to barge in here, but it seems to me that your disagreement is not necessarily a principle stance, but merely the fact that different people have different principle stances that conflict. And so they conflict and if one party wants upstream to happen first and the other party wants downstream to happen first, you are at a stalemate. And it is not so much because intermixing seems bad but because you have a practical problem which is that some developer refuses to do something because it hasn't been upstreamed yet. This refusal that you considered perfectly reasonable seems the only obstacle here for you. And then it becomes a problem if other people do not also follow that principle. But instead of making other people more strict, I would suggest you focus on making the other party less strict. It seems this strictness is the only problem here, instead of the solution. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 02:47 PM, Greg KH wrote: In the meantime, to object to other developers doing work on systemd to test out these changes seems very odd, who are you, or me, to tell someone else what they can or can not do with their project? Interesting philosophical question as to who owns the project Lennart? Those that contributed lines to it and if so do those contributors just "own" their lines ( do I own my contributed lines in the project and have a saying on how they are used , I dont think so ) in the codebase? is it the community and users surrounding it ( since without it would be meaningless) ? who? Questions in which people can and probably would debate about to death and beyond for decades. + This is about consistency as in about Lennart and others drawing the line of having code accepted upstream *before* being taken advantage of, used and merged into the project. An policy I myself whole heartily agree with but at the same time they themselves are not following that rule which makes that policy the whole definition of hypocrisy does it not? If the line has been raised from having to be accepted upstream first to being *preferred* being accepted upstream first than that's ok, no longer hypocrisy and inline with my original mail, contributors and downstream expectation adjusted accordingly which I would assume would be aligned with the kdbus experience in which years was spent in having that committed into the upstream kernel, integration was made into systemd and elsewhere, downstream *encourage* to pick it up and begin testing it [1] with the added load and changes ( implementing/reverting ) in contributed/paid time that costed contributors downstream. An costly experience that would have never come to pass if previous rule that was drawed in the sand had been followed to the letter. I personally recommend the project should stick with the original line drew in the sand, for the master branch and all the "experimental" stuff which may or may not come to pass, be kept in it's own experimental branch which would be the best of the both worlds I would think. Downstream that want stability get what they want and are less likely to experience any sudden *surprises* and those that want the experimental stuff for whatever reason like testing get what they want. JBG 1. https://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 01:55:34PM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 12:53 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:34 PM, Greg KH wrote: > > > > > > But agreement is usually the best way to work things out, > don't you > > > think? Isn't it better than the traditional way a company > works (a > > > project manager says "this has to be merged!")? > > > > > Agreed mutual agreement is the best course of action always but > sometimes > > drastic measures will need to be taken to break status quo. > > Which is what happens when needed. We've been doing this for a long > time now, you would think that people would trust us by now... > > > Less to do with trust more to do with the fact If that process was working, > Tejun Heo changes would have been merged ( or some mutual agreement reached on > the way forward ) and we would not be having this discussion here in the first > place. One might argue that the process _is_ working as planned, the review comments are valid ones and need to be addressed. Anyway, this whole argument is totally pointless, just let the upstream development process work its way through the issues, and see what happens. In the meantime, to object to other developers doing work on systemd to test out these changes seems very odd, who are you, or me, to tell someone else what they can or can not do with their project? good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 12:53 PM, Greg KH wrote: On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote: >On 08/16/2016 12:34 PM, Greg KH wrote: > > >But agreement is usually the best way to work things out, don't you > >think? Isn't it better than the traditional way a company works (a > >project manager says "this has to be merged!")? > >Agreed mutual agreement is the best course of action always but sometimes >drastic measures will need to be taken to break status quo. Which is what happens when needed. We've been doing this for a long time now, you would think that people would trust us by now... Less to do with trust more to do with the fact If that process was working, Tejun Heo changes would have been merged ( or some mutual agreement reached on the way forward ) and we would not be having this discussion here in the first place. I would be living in my black and white world in which everything is dictated and dominated by cause and effect equal and opposite reaction, the black and white, the zeros and ones and you would be living in your "gray area" plane of existence hunting pokemons or doing whatever floats your boat;) JB. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 12:51 PM, Greg KH wrote: On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote: Irrelevant. No, not at all, I'm just really confused as to what systemd changes are required to get wireguard working properly with it? Think of it like native integration with .network files and the likes as in the interface would be configured ||with it as opposed to be using wireguards own configuration file but as I said it's irrelevant since how and to what extent is subjected to changes once Susant and Tom have had a chance to review such work but before any such work can be started Jason needs to submit the relevant bits to be included in the kernel first which afaik he has still not done. No biscuits and marmalade and until the hottest (vpn) kid on the block has been merged upstream. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:31 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote: > > > > > > On 08/16/2016 11:28 AM, Greg KH wrote: > > > > On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: > > > > > > Such as what specifically? > > Are you pretending you are going to be reviewing this now? I'm saying I care about wireguard and want to see it succeed. > > Do other VPNs require changes to systemd in > > some way? > > Irrelevant. No, not at all, I'm just really confused as to what systemd changes are required to get wireguard working properly with it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 12:34 PM, Greg KH wrote: But agreement is usually the best way to work things out, don't you think? Isn't it better than the traditional way a company works (a project manager says "this has to be merged!")? Agreed mutual agreement is the best course of action always but sometimes drastic measures will need to be taken to break status quo. Did not the filesystem maintainers all get locked in a room until they could agree on the way forward in which they where let out of the room again and out came btrfs ;) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 12:34 PM, Greg KH wrote: > > > But agreement is usually the best way to work things out, don't you > > think? Isn't it better than the traditional way a company works (a > > project manager says "this has to be merged!")? > > Agreed mutual agreement is the best course of action always but sometimes > drastic measures will need to be taken to break status quo. Which is what happens when needed. We've been doing this for a long time now, you would think that people would trust us by now... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 12:35:13PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 12:13 PM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote: > > > Why cant the kernel community figure this out and solve this upstream > > > first > > > since it's quite obvious from the threads that Tejun Heo linked to in > > > that pull > > > request that this is a political issue not a technical one. > > > > > > Surely Linus and his so called lieutenants can step in and break political > > > status quo like that. > > That makes no sense at all, sorry. Work with the upstream developers to > > get this resolved, that's all that anyone can do here. > > So each maintainer can prevent changeset from being merged if affect the > area he ( currently ) maintains the kernel. No one has "absolute" control, sorry, that's not how we work. But agreement is usually the best way to work things out, don't you think? Isn't it better than the traditional way a company works (a project manager says "this has to be merged!")? > That's interesting and begs the question how much time and energy the kernel > community spend in resolving matters that stem from "opinions" and people > stubbornness? Please feel free to show how this is true, I don't see this at all. And you do realize that the kernel is the largest (by number of contributors and different companies), and fastest moving, software project ever in the history of computing? Perhaps the model that we have does work pretty well :) greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 12:31 PM, Greg KH wrote: On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote: On 08/16/2016 11:28 AM, Greg KH wrote: On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: Such as what specifically? Are you pretending you are going to be reviewing this now? Do other VPNs require changes to systemd in some way? Irrelevant. Why are you so fixated on this since his stance is arguably the correct one on refusing this in the first place *until* this has been implemented in the upstream kernel which arguably and should have been done in relation with cgroup v2 until that got sorted out. Who is "his"? Tom if you must know but that view was shared with Kay and Lennart at one point. Are you against the policy of upstreaming first? The world is not black and white :) Aha like saving the planet has anything to do with saving the planet but you have answered what I asked. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 12:13 PM, Greg KH wrote: On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote: Why cant the kernel community figure this out and solve this upstream first since it's quite obvious from the threads that Tejun Heo linked to in that pull request that this is a political issue not a technical one. Surely Linus and his so called lieutenants can step in and break political status quo like that. That makes no sense at all, sorry. Work with the upstream developers to get this resolved, that's all that anyone can do here. So each maintainer can prevent changeset from being merged if affect the area he ( currently ) maintains the kernel. That's interesting and begs the question how much time and energy the kernel community spend in resolving matters that stem from "opinions" and people stubbornness? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 11:28 AM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: > > > > > > On 08/16/2016 10:44 AM, Greg KH wrote: > > > > On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > > > > > 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. > > > > Wait, what needs to be added to systemd to get wireguard "working" > > > > properly? It's just like any other network VPN service, what makes it > > > > special (well, becides the very coolness of it of course...) > > > > > > > > Were there patches that were rejected? Any pointers to them? > > > The patches have not been written yet because the systemd developer > > > mentioned he would not accept it until this was merged upstream. > > Again, what type of patches to systemd are needed for wireguard? > > > > For example changes to networkd configuration files. Such as what specifically? Do other VPNs require changes to systemd in some way? > Why are you so fixated on this since his stance is arguably the correct one > on refusing this in the first place *until* this has been implemented in the > upstream kernel which arguably and should have been done in relation with > cgroup v2 until that got sorted out. Who is "his"? > Are you against the policy of upstreaming first? The world is not black and white :) thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 10:42 AM, Greg KH wrote: > > As long as this new code doesn't break things for users without those > kernel patches, why would you object? Are you having to maintain these > new features for some reason? > > > No but I eventually might have to deal with the fallout from such approach. Really? How? > Why cant the kernel community figure this out and solve this upstream first > since it's quite obvious from the threads that Tejun Heo linked to in that > pull > request that this is a political issue not a technical one. > > Surely Linus and his so called lieutenants can step in and break political > status quo like that. That makes no sense at all, sorry. Work with the upstream developers to get this resolved, that's all that anyone can do here. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 11:28 AM, Greg KH wrote: On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: On 08/16/2016 10:44 AM, Greg KH wrote: On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: 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. Wait, what needs to be added to systemd to get wireguard "working" properly? It's just like any other network VPN service, what makes it special (well, becides the very coolness of it of course...) Were there patches that were rejected? Any pointers to them? The patches have not been written yet because the systemd developer mentioned he would not accept it until this was merged upstream. Again, what type of patches to systemd are needed for wireguard? For example changes to networkd configuration files. Why are you so fixated on this since his stance is arguably the correct one on refusing this in the first place *until* this has been implemented in the upstream kernel which arguably and should have been done in relation with cgroup v2 until that got sorted out. Are you against the policy of upstreaming first? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote: > > > On 08/16/2016 10:44 AM, Greg KH wrote: > > On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > > > 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. > > Wait, what needs to be added to systemd to get wireguard "working" > > properly? It's just like any other network VPN service, what makes it > > special (well, becides the very coolness of it of course...) > > > > Were there patches that were rejected? Any pointers to them? > > The patches have not been written yet because the systemd developer > mentioned he would not accept it until this was merged upstream. Again, what type of patches to systemd are needed for wireguard? confused, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 10:42 AM, Greg KH wrote: As long as this new code doesn't break things for users without those kernel patches, why would you object? Are you having to maintain these new features for some reason? No but I eventually might have to deal with the fallout from such approach. Why cant the kernel community figure this out and solve this upstream first since it's quite obvious from the threads that Tejun Heo linked to in that pull request that this is a political issue not a technical one. Surely Linus and his so called lieutenants can step in and break political status quo like that. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 10:27 AM, Lennart Poettering wrote: On Tue, 16.08.16 10:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: 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? Because we want this stuff in the hands of people. In fact, we are interested into seeing the matching kernel patch in Fedora kernels too, in order to make sure this gets more presence. I have to ask to what end? This was not accepted upstream so is the plan here to expose this to larger use base, have downstream make the necessary changes to somehow pressure the upstream kernel community to accept this? If Red Hat wants the Fedora community to implement this "for testing and exposure" for their clients and business partners they should do so via copr repo along with a kernel that contains this patch and any exposed bugs wont get fixed in the kernel community since this has not been accepted right + the first one that get's bitten by any regression this might introduced would be the Arch community and probably CoreOS/Google long before the Fedora community ( Fedora is not leading anything anymore other than it's community members in circles ) who are running like headless chickens now after the failed implementation of Red Hat product ( read as the products/editions/WG's ) which has made the distribution worse off than it was when it was "generic" but there is an effort now making Fedora generic again called "modular" so it can be everything to anyone just like it was before and that circle will complete itself. And cgroupsv2 isn't just some entirely random thing: it fixes major bugs for us, and is at the core what systemd does. Which arguably is even more of a reason why un-merged upstream changes should not be implemented since fluctuating changes to such a core implementation in systemd can cause serious regression for downstream(s). What's the long term plan here if the kernel community never accepts this? What are you planning to do then and how do you expect downstreams to handle that? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 10:44 AM, Greg KH wrote: On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: 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. Wait, what needs to be added to systemd to get wireguard "working" properly? It's just like any other network VPN service, what makes it special (well, becides the very coolness of it of course...) Were there patches that were rejected? Any pointers to them? The patches have not been written yet because the systemd developer mentioned he would not accept it until this was merged upstream. Which is a perfectly legit perspective. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > 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. Wait, what needs to be added to systemd to get wireguard "working" properly? It's just like any other network VPN service, what makes it special (well, becides the very coolness of it of course...) Were there patches that were rejected? Any pointers to them? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote: > On 08/16/2016 09:04 AM, Lennart Poettering wrote: > > On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > Johann, what you are posting here is really not helpful in any > way. > > > 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. There is code in the udev binary that works for kernel patches that have remained out-of-tree for 8+ years. Are you going to rip that out now? :) Sometimes you have to add code to projects in order to be able to properly test the kernel code. And to make it easier for people to upgrade their kernels in the future and have things work properly on their existing, older, system tools. This happens all the time, I don't know why you are suddenly surprised about this. As long as this new code doesn't break things for users without those kernel patches, why would you object? Are you having to maintain these new features for some reason? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Tue, 16.08.16 10:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > 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? Because we want this stuff in the hands of people. In fact, we are interested into seeing the matching kernel patch in Fedora kernels too, in order to make sure this gets more presence. And cgroupsv2 isn't just some entirely random thing: it fixes major bugs for us, and is at the core what systemd does. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 09:06 AM, Lennart Poettering wrote: On Mon, 15.08.16 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: The world isn't just black and white, you know. That depends entirely on ones perception of the world does it not? I'm interesting to hear when it is not but such philosophical discussion are probably best served over a beer. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/16/2016 09:04 AM, Lennart Poettering wrote: On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Johann, what you are posting here is really not helpful in any way. 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. 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Johann, what you are posting here is really not helpful in any way. 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Mon, 15.08.16 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > Due to the lack of consensus in the kernel community, the CPU controller > > support on the unified cgroup hierarchy requires out-of-tree kernel > > patches. > > See cgroup-v2-cpu.txt[3]. > > > >I think that's pretty clear. If you think it should be made more clear, let > >me know how. > > Irrelevant if it's clear or not and repeating does not change the > fact that merging this into the master branch means the policy of > upstream first no longer applies so it can never be used as an > argument used against merging submitted code against the entire > systemd codebase. The world isn't just black and white, you know. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On 08/15/2016 04:08 PM, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Aug 15, 2016 at 10:53:56AM +, Jóhann B. Guðmundsson wrote: >Just a heads up based on the merge of [1] systemd no longer >requires features to have been accepted in the upstream kernel >before merging it. See the man page: Due to the lack of consensus in the kernel community, the CPU controller support on the unified cgroup hierarchy requires out-of-tree kernel patches. See cgroup-v2-cpu.txt[3]. I think that's pretty clear. If you think it should be made more clear, let me know how. Irrelevant if it's clear or not and repeating does not change the fact that merging this into the master branch means the policy of upstream first no longer applies so it can never be used as an argument used against merging submitted code against the entire systemd codebase. This ought have been rejected or resided in it's own "experimental" branch of the systemd codebase until they have sorted the cgroupv2 stuff out upstream. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.
On Mon, Aug 15, 2016 at 10:53:56AM +, Jóhann B. Guðmundsson wrote: > Just a heads up based on the merge of [1] systemd no longer > requires features to have been accepted in the upstream kernel > before merging it. See the man page: Due to the lack of consensus in the kernel community, the CPU controller support on the unified cgroup hierarchy requires out-of-tree kernel patches. See cgroup-v2-cpu.txt[3]. I think that's pretty clear. If you think it should be made more clear, let me know how. Also, I'll repeat what I wrote on the PR: that patch has no effect on v1 users, or on v2-vanilla-kernel users, and only affects v2-patched-kernel users. And what Tejun Heo said: the opposition upstream is not to the details of the interface, but to general cgroups-v2 design. It's a bit late for that, but even if the design is significantly changed, the interface is likely to be as proposed in those patches. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Head ups - upstream first no longer applies to the kernel.
Just a heads up based on the merge of [1] systemd no longer requires features to have been accepted in the upstream kernel before merging it. Adjust you expectation accordingly for submission and potential downstream breakage for type units in which upstream might have decided to take advantages of such merged features in systemd. JBG 1. https://github.com/systemd/systemd/pull/3905 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel