1 |
On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: |
2 |
> > I'm genuinely interested in your goals, in detail, otherwise I would |
3 |
> > not have asked about them. Perhaps I am totally wrong and your fork |
4 |
> > makes sense, perhaps, to me, not. But without knowing such goals, |
5 |
> > there's no way that anyone can get an idea about this. |
6 |
> |
7 |
> I am afraid that I have to disappoint you. If we were using the |
8 |
> waterfall model, I could outline some very nice long term goals for you, |
9 |
> but we are doing AGILE development, so long term goals have not been |
10 |
> well defined. Some short term goals have been defined, but I imagine |
11 |
> that you are already familiar with them. I suggest asking again after |
12 |
> our first tag. |
13 |
|
14 |
I'll ignore the fact that project goals have nothing to do with |
15 |
waterfall or agile, and ask, what are your short-term goals? |
16 |
|
17 |
Why is this an "official" Gentoo project without this being discussed in |
18 |
an open manner? |
19 |
|
20 |
> A consequence of being open source means that everyone can see what we |
21 |
> do, so people are able to send us their opinions on things that have not |
22 |
> been officially announced, much like this project. |
23 |
|
24 |
Given that the Gentoo Foundation is claiming copyright on this project |
25 |
now, not announcing it seems a bit rude to the rest of us who make up |
26 |
this foundation, don't you think? |
27 |
|
28 |
That's not very open :( |
29 |
|
30 |
> >>>>> I understand the bizarre need of some people to want to build the udev |
31 |
> >>>>> binary without the build-time dependencies that systemd requires, but |
32 |
> >>>>> surely that is a set of simple Makefile patches, right? And is |
33 |
> >>>>> something that small really worth ripping tons of code out of a working |
34 |
> >>>>> udev, causing major regressions on people's boxes (and yes, it is a |
35 |
> >>>>> regression to slow my boot time down and cause hundreds of more |
36 |
> >>>>> processes to be spawned before booting is finished.) |
37 |
> >>>> |
38 |
> >>>> See the following: |
39 |
> >>>> |
40 |
> >>>> https://github.com/gentoo/eudev/issues/3 |
41 |
> >>> |
42 |
> >>> You moved from an explicit to an implicit dependency. It's not |
43 |
> >>> inspiring any sense of confidence from me that there is an understanding |
44 |
> >>> of how things work here. |
45 |
> >>> |
46 |
> >>> Seriously, the codebase you are working with isn't that large, or |
47 |
> >>> complex, at all. To go rip stuff out, only to want to add it back in |
48 |
> >>> later, wastes time, causes bugs, and goes against _any_ software |
49 |
> >>> methodology that I know of. |
50 |
> >> |
51 |
> >> I can say the same about the manner in which these changes were |
52 |
> >> introduced. Ripping them out to get the codebase back into a state from |
53 |
> >> which we are comfortable moving forward is the only sane way of dealing |
54 |
> >> with them. |
55 |
> > |
56 |
> > Wait, what? The kmod introduction was deliberate and solves a real |
57 |
> > problem. kmod itself was created _because_ of these issues that had |
58 |
> > been seen and found. It was written for the systemd/udev projects to |
59 |
> > use, and had been worked on for a long time by a number of developers. |
60 |
> > By removing it, you have now negated that solution and we are back to |
61 |
> > the old problems we had before. That doesn't seem very wise to me, does |
62 |
> > it to you? |
63 |
> > |
64 |
> > thanks, |
65 |
> > |
66 |
> > greg k-h |
67 |
> |
68 |
> Having a builtin is a good idea, but the implementation as a mandatory |
69 |
> dependency on kmod is not. The plan is to reintroduce it as an optional |
70 |
> dependency, so that distributions (and Gentoo users) that do not want it |
71 |
> can avoid it. None of us want to force dependencies on others and there |
72 |
> is no need for this one. |
73 |
|
74 |
You do realize that you didn't really drop the dependency at all, right? |
75 |
|
76 |
> With that said, Linux distributions are victims of people continually |
77 |
> trying to reinvent the wheel with no formal planning. |
78 |
|
79 |
Huh? Really? It's as if you think we all are just throwing stuff |
80 |
against the wall and seeing what sticks? We aren't responding to real |
81 |
users, customers, research, history, and competitors? Your dismissal of |
82 |
the people who create the system you are using seems pretty bold. |
83 |
|
84 |
> At some point, someone has to enforce a form of structure where |
85 |
> further change occurs in a well defined manner and change because we |
86 |
> can is rejected as being pointless. That is what we want and that is |
87 |
> what we feel that our users want. |
88 |
|
89 |
Ok, what is that structure you are wishing were present? What problems |
90 |
do you have with systemd on a technical level that are not being |
91 |
addressed? What technical problems with udev do you have that caused |
92 |
this to be forked? What problems are you wishing to solve, and what |
93 |
goals do you have by doing all of this? |
94 |
|
95 |
Have you studied the problem area for booting, process monitoring, |
96 |
system isolation, device creation and notification, persistant naming, |
97 |
multiple users with multiple displays, and the like, and found that |
98 |
Linux is lacking in this area? If so, I would love to learn more, as I |
99 |
want Linux, and Gentoo, to succeed. Without knowing the problems you |
100 |
are having, there's no way anyone will ever change. |
101 |
|
102 |
thanks, |
103 |
|
104 |
greg k-h |