Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: Linux 4.19-rc4 released, an apology, and a maintainership note
To:     "Eric W. Biederman" <ebiederm@xmission.com>,
        Pavel Snajdr <snajpa@snajpa.net>
Cc:     michaeljpwoods@gmail.com, linux-kernel@vger.kernel.org
References: <CA+55aFy+Hv9O5citAawS+mVZO+ywCKd9NQ2wxUmGsz9ZJzqgJQ@mail.gmail.com>
 <93424bb0-180e-71ff-f0d6-602caa2d5883@gmail.com>
 <260205ec45d097fb037f71ae42e7b69e@snajpa.net> <87murtg3ow.fsf@xmission.com>
From:   "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Organization: metux IT consult
Message-ID: <56371a32-14c9-f59c-c98f-2414650d8505@metux.net>
Date:   Mon, 8 Oct 2018 17:29:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87murtg3ow.fsf@xmission.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 04.10.2018 16:57, Eric W. Biederman wrote:

> Very often people will propose patches that do solve their specific case
> but only do 10% or maybe 20% of what is needed for a general kernel
> level solution.  For something that just works and does not cause
> maintenance problems in the long run.

One of the cases is the hard realtime stuff. A perfect implementation
for hard-RT environments can easily turn out as total crap for
generic server workloads. So, these things really take time make both
worlds fit together. For those cases, it's often better to maintain
it as a separate tree/patchset and step by step try to bring those
pieces to mainline, that fit in there.

> I know many other maintainers get hit with such a stream of bad
> container ideas that they tend to stop listening.  As their priorities
> are elsewhere I don't blame them.

Let's put it that way: these ideas probaly aren't necessarily bad as
such, but just don't fit into mainline (yet).

OVZ is such a case: it's s good thing for a range of usecases, and
pretty successful there. But it conflicts lots of other places that the
mainline has to support. Therefore it has to stay a separate tree, until
we've found a better solution, somewhere in the future.

> Similarly because maintainers have a limited amount of time there are no
> guarantees how much we can help others.  We can try but people have to
> meet maintainers at least half way in figuring out how things work
> themselves, and sometimes there is just not enough time to say anything.

Yes. I've been demotivated by this problem myself. But I know, I can't
expect anybody else do to my homework for me.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287