[systemd-devel] [ANNOUNCE] Preliminary systemd.conf 2016 Schedule Available!

2016-08-16 Thread Lennart Poettering
Heya!

We have published a preliminary version of the systemd.conf 2016
schedule:

https://cfp.systemd.io/en/systemdconf_2016/public/schedule/1

There is a small number of white slots in the schedule still, because
we're missing confirmation from a small number of presenters. The
missing talks will be added in as soon as they are confirmed.

The schedule consists of 5 workshops by high-profile speakers during
the workshop day, 22 exciting talks during the main conference days,
followed by one full day of hackfests.

Please sign up for the conference soon! Only a limited number of
tickets are available, hence make sure to secure yours quickly before
they run out! (Last year we sold out.) Please sign up here for the
conference:

https://ti.to/systemdconf/systemdconf-2016

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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Greg KH
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


[systemd-devel] systemd-nspawn overlay and rootfs

2016-08-16 Thread Juanjo Presa
Hi, I'm trying to compose a container with several layers and join together
with overlay option but seems that is not supported.

I want to get something like:
systemd-nspawn --overlay=/foo/ubuntu-base:/foo/app-runtime:/foo/app:/ -D
/foo/bar --boot

Maybe I'm misunderstanding the overlay option.

So, what do you suggest to accomplish a similar model. Maybe just mount the
desired overlay sideways in /foo/bar and dismiss systemd-nspawn overlay
option? Something similar with btrfs subvolumes?

Thanks in advance.
___
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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Greg KH
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.

2016-08-16 Thread Lennart Poettering
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.

2016-08-16 Thread Jóhann B . Guðmundsson



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.

2016-08-16 Thread Jóhann B . Guðmundsson

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.

2016-08-16 Thread Lennart Poettering
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.

2016-08-16 Thread Lennart Poettering
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