On 11/17/2012 11:35 PM, Greg KH wrote: > On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: >> On 11/17/2012 11:19 PM, Greg KH wrote: >>> On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: >>>> On 11/17/2012 10:29 PM, Greg KH wrote: >>>>> I see an "entertaining" fork of udev on github at the moment (-ng, >>>>> really? What happens when someone wants to fork that, -ng-ng? Be a bit >>>>> more original in your naming please, good thing I never trademarked >>>>> "udev" all those years ago, maybe I still should...) >>>> >>>> That was a placeholder name. If you checked before you sent your email, >>>> you would see that we had settled on eudev. >>> >>> The name change still doesn't make it any less "entertaining" :) >>> >>> What does the "e" stand for? >> >> That is a common question. Someone associated with Canonical suggested >> that e stand for embedded. Others consider the "eu" prefix to be the >> greek root for "true". Honestly, we don't care. It is just a name. > > I wouldn't pick "embedded" as the embedded world is now using systemd as > it meets their requirements much better than anything else :)
As far as I know, they are using busybox. >>>>> But, along those lines, what is the goal of the fork? What are you >>>>> trying to attempt to do with a fork of udev that could not be >>>>> accomplished by: >>>>> - getting patches approved upstream >>>>> or: >>>>> - keeping a simple set of patches outside of the upstream tree and >>>>> applying them to each release >>>> >>>> The goal is to replace systemd as upstream for Gentoo Linux, its >>>> derivatives and any distribution not related to RedHat. >>> >>> Wait, really? You want to replace systemd? Then why are you starting >>> at udev and not systemd? >>> >>> What is wrong with systemd that it requires a fork? All other distros >>> seem to be participating in the development process of systemd quite >>> well, what is keeping Gentoo developers from also doing the same? >>> >>> What are your goals, specifically, in detail. >> >> Is there any way that the answer to your inquiry would result in a >> productive conversation where you would not attempt to dictate what we do? > > I'm genuinely interested in your goals, in detail, otherwise I would > not have asked about them. Perhaps I am totally wrong and your fork > makes sense, perhaps, to me, not. But without knowing such goals, > there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. A consequence of being open source means that everyone can see what we do, so people are able to send us their opinions on things that have not been officially announced, much like this project. >>>>> I understand the bizarre need of some people to want to build the udev >>>>> binary without the build-time dependencies that systemd requires, but >>>>> surely that is a set of simple Makefile patches, right? And is >>>>> something that small really worth ripping tons of code out of a working >>>>> udev, causing major regressions on people's boxes (and yes, it is a >>>>> regression to slow my boot time down and cause hundreds of more >>>>> processes to be spawned before booting is finished.) >>>> >>>> See the following: >>>> >>>> https://github.com/gentoo/eudev/issues/3 >>> >>> You moved from an explicit to an implicit dependency. It's not >>> inspiring any sense of confidence from me that there is an understanding >>> of how things work here. >>> >>> Seriously, the codebase you are working with isn't that large, or >>> complex, at all. To go rip stuff out, only to want to add it back in >>> later, wastes time, causes bugs, and goes against _any_ software >>> methodology that I know of. >> >> I can say the same about the manner in which these changes were >> introduced. Ripping them out to get the codebase back into a state from >> which we are comfortable moving forward is the only sane way of dealing >> with them. > > Wait, what? The kmod introduction was deliberate and solves a real > problem. kmod itself was created _because_ of these issues that had > been seen and found. It was written for the systemd/udev projects to > use, and had been worked on for a long time by a number of developers. > By removing it, you have now negated that solution and we are back to > the old problems we had before. That doesn't seem very wise to me, does > it to you? > > thanks, > > greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. At some point, someone has to enforce a form of structure where further change occurs in a well defined manner and change because we can is rejected as being pointless. That is what we want and that is what we feel that our users want.
signature.asc
Description: OpenPGP digital signature
