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
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
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
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
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
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 +,
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
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
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
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
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
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 +,
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
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
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
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
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
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
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
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.
>
>
>
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
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
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
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
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
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,
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
27 matches
Mail list logo
