1 |
On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: |
2 |
> On 11/17/2012 11:19 PM, Greg KH wrote: |
3 |
> > On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: |
4 |
> >> On 11/17/2012 10:29 PM, Greg KH wrote: |
5 |
> >>> I see an "entertaining" fork of udev on github at the moment (-ng, |
6 |
> >>> really? What happens when someone wants to fork that, -ng-ng? Be a bit |
7 |
> >>> more original in your naming please, good thing I never trademarked |
8 |
> >>> "udev" all those years ago, maybe I still should...) |
9 |
> >> |
10 |
> >> That was a placeholder name. If you checked before you sent your email, |
11 |
> >> you would see that we had settled on eudev. |
12 |
> > |
13 |
> > The name change still doesn't make it any less "entertaining" :) |
14 |
> > |
15 |
> > What does the "e" stand for? |
16 |
> |
17 |
> That is a common question. Someone associated with Canonical suggested |
18 |
> that e stand for embedded. Others consider the "eu" prefix to be the |
19 |
> greek root for "true". Honestly, we don't care. It is just a name. |
20 |
|
21 |
I wouldn't pick "embedded" as the embedded world is now using systemd as |
22 |
it meets their requirements much better than anything else :) |
23 |
|
24 |
> >>> But, along those lines, what is the goal of the fork? What are you |
25 |
> >>> trying to attempt to do with a fork of udev that could not be |
26 |
> >>> accomplished by: |
27 |
> >>> - getting patches approved upstream |
28 |
> >>> or: |
29 |
> >>> - keeping a simple set of patches outside of the upstream tree and |
30 |
> >>> applying them to each release |
31 |
> >> |
32 |
> >> The goal is to replace systemd as upstream for Gentoo Linux, its |
33 |
> >> derivatives and any distribution not related to RedHat. |
34 |
> > |
35 |
> > Wait, really? You want to replace systemd? Then why are you starting |
36 |
> > at udev and not systemd? |
37 |
> > |
38 |
> > What is wrong with systemd that it requires a fork? All other distros |
39 |
> > seem to be participating in the development process of systemd quite |
40 |
> > well, what is keeping Gentoo developers from also doing the same? |
41 |
> > |
42 |
> > What are your goals, specifically, in detail. |
43 |
> |
44 |
> Is there any way that the answer to your inquiry would result in a |
45 |
> productive conversation where you would not attempt to dictate what we do? |
46 |
|
47 |
The only thing I'm "telling" anyone to do is to fix the copyright mess |
48 |
they created, as it is a legal liability for the Gentoo Foundation, |
49 |
which I care about. That HAS to be resolved. |
50 |
|
51 |
I'm genuinely interested in your goals, in detail, otherwise I would |
52 |
not have asked about them. Perhaps I am totally wrong and your fork |
53 |
makes sense, perhaps, to me, not. But without knowing such goals, |
54 |
there's no way that anyone can get an idea about this. |
55 |
|
56 |
> >>> I understand the bizarre need of some people to want to build the udev |
57 |
> >>> binary without the build-time dependencies that systemd requires, but |
58 |
> >>> surely that is a set of simple Makefile patches, right? And is |
59 |
> >>> something that small really worth ripping tons of code out of a working |
60 |
> >>> udev, causing major regressions on people's boxes (and yes, it is a |
61 |
> >>> regression to slow my boot time down and cause hundreds of more |
62 |
> >>> processes to be spawned before booting is finished.) |
63 |
> >> |
64 |
> >> See the following: |
65 |
> >> |
66 |
> >> https://github.com/gentoo/eudev/issues/3 |
67 |
> > |
68 |
> > You moved from an explicit to an implicit dependency. It's not |
69 |
> > inspiring any sense of confidence from me that there is an understanding |
70 |
> > of how things work here. |
71 |
> > |
72 |
> > Seriously, the codebase you are working with isn't that large, or |
73 |
> > complex, at all. To go rip stuff out, only to want to add it back in |
74 |
> > later, wastes time, causes bugs, and goes against _any_ software |
75 |
> > methodology that I know of. |
76 |
> |
77 |
> I can say the same about the manner in which these changes were |
78 |
> introduced. Ripping them out to get the codebase back into a state from |
79 |
> which we are comfortable moving forward is the only sane way of dealing |
80 |
> with them. |
81 |
|
82 |
Wait, what? The kmod introduction was deliberate and solves a real |
83 |
problem. kmod itself was created _because_ of these issues that had |
84 |
been seen and found. It was written for the systemd/udev projects to |
85 |
use, and had been worked on for a long time by a number of developers. |
86 |
By removing it, you have now negated that solution and we are back to |
87 |
the old problems we had before. That doesn't seem very wise to me, does |
88 |
it to you? |
89 |
|
90 |
thanks, |
91 |
|
92 |
greg k-h |