On 11/18/2012 12:19 AM, Greg KH wrote: > On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: >>> 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. > > I'll ignore the fact that project goals have nothing to do with > waterfall or agile, and ask, what are your short-term goals? > > Why is this an "official" Gentoo project without this being discussed in > an open manner?
We are in the process of getting started. If you read my original email, you would know that the announcement was supposed to occur relatively soon. The reason I sent it was because the Gentoo Council meeting required something be sent sooner than we were ready. >> 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. > > Given that the Gentoo Foundation is claiming copyright on this project > now, not announcing it seems a bit rude to the rest of us who make up > this foundation, don't you think? > > That's not very open :( Actually, that is one developer who asked if he could join the project and thought that he was being helpful. I insisted that those changes go into a branch because I felt that they could cause problems. >>>>>>> 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. > > You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? >> With that said, Linux distributions are victims of people continually >> trying to reinvent the wheel with no formal planning. > > Huh? Really? It's as if you think we all are just throwing stuff > against the wall and seeing what sticks? We aren't responding to real > users, customers, research, history, and competitors? Your dismissal of > the people who create the system you are using seems pretty bold. The result of what the existing people have been doing has been the equivalent of throwing stuff against the wall for many of us. We have decided to try doing things ourselves to see if we can do better. We think we can. >> 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. > > Ok, what is that structure you are wishing were present? What problems > do you have with systemd on a technical level that are not being > addressed? What technical problems with udev do you have that caused > this to be forked? What problems are you wishing to solve, and what > goals do you have by doing all of this? > > Have you studied the problem area for booting, process monitoring, > system isolation, device creation and notification, persistant naming, > multiple users with multiple displays, and the like, and found that > Linux is lacking in this area? If so, I would love to learn more, as I > want Linux, and Gentoo, to succeed. Without knowing the problems you > are having, there's no way anyone will ever change. We already have OpenRC, which has been found to work well on both Gentoo Linux and Gentoo FreeBSD. The integration of udev into systemd has caused problems for existing OpenRC systems with people being told that it is okay to break configurations that users had been told to use over well over a decade. Many of us consider that to be unacceptable. Anyway, results are what are important. If you are interested in what we are doing, then I suggest coming back in a month to see what we have produced.
signature.asc
Description: OpenPGP digital signature
