Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 04 Oct 2018 16:57:19 +0200 | Subject | Re: Linux 4.19-rc4 released, an apology, and a maintainership note |
| |
Pavel Snajdr <snajpa@snajpa.net> writes: > > We started our organization (vpsFree.org) on top of OpenVZ patch set and are now > working to get vanilla up to the task of replacing the venerable 2.6.32-based > OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that > we won't be laughed out of the room and that our members won't be demotivated > to contribute upstream - if we can all agree to be nice on each other; yet we > still need you guys to tell us, when we're trying stupid things or going about > things the wrong way, in some way that we will notice & can learn from. > If I understand the context correctly, the previous "regime" could be the > culprit, at least to some extent, why still don't have the VM look&feel-having > containers with vanilla.
At an implementation level namespaces and cgroups are hard. Coming up with a good solid design that is very maintainable and handles all of the corner cases is difficult. Very few people choose to do the work of digging into the details and figuring out what is really needed.
This is not an area where you can hand hold someone. It really takes people who are able to work out from first principles what the code will need to do.
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.
Someone has to deep dive and understand all of the problems and sort it out.
That takes a person that is willing and able to stand up with all of the rest of the kernel developers as an equal. It requires listening to other opinions to see where you need to change and where things are wrong but it also requires being able to figure things out for yourself and to come up with solid technical contributions.
I hope I have been something reasonable to work with on this front, if not please let me know.
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.
Also don't forget that most of the time to do a good implemenation that it requires rewriting an entire subsystem to make it container friendly. Think of the effort that requires, especially when you are not allowed to cause regressions in the subystem while rewriting it.
Further the only power a maintainer has is to accept patches, to listen to people, and to express opinions that are worth listening to. In the midst of doing all of those things a maintainers time is limited.
You said a change in attitude gives you optimism that you can make work with the upstream kernel. I am glad you have optimism as overall the kernel is a welcoming place.
At the same time there can't be guarantees that people won't be demontivated. If you care about the remaining kernel problems for implementing containers, you need to realize those that are difficult problems that don't easily admit to solutions. That is why the problems still remain. To get a small flavor just look at how much work I had to go through to sort out siginfo in the kernel which is just one very small piece of the larger puzzle. So please realize that sometimes actually realizing the scope of the technical difficulties might be demotivating in and of itself.
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. As the old saying goes: "You can lead a horse to water but you can't make him drink".
So there are no guarantees that people won't be demotivated or that they will learn what is necessary. All that we can do is aim to keep conversations polite and focused on the technical details of the project. Which should keep things from getting unpleasant at the level of humans interacting with humans. I don't think that will give you greater guarantees beyond that, and it feels like you are reading greater guarantees into recent events.
I would like to see what you see as missing from the mainline kernel. But that is a topic for the containers list, and possibly for the containers track at Linux Plumbers conference in Vancouver.
Eric
| |