| 1 |
On 11/17/2012 11:19 PM, Greg KH wrote: |
| 2 |
> On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: |
| 3 |
>> On 11/17/2012 10:29 PM, Greg KH wrote: |
| 4 |
>>> I see an "entertaining" fork of udev on github at the moment (-ng, |
| 5 |
>>> really? What happens when someone wants to fork that, -ng-ng? Be a bit |
| 6 |
>>> more original in your naming please, good thing I never trademarked |
| 7 |
>>> "udev" all those years ago, maybe I still should...) |
| 8 |
>> |
| 9 |
>> That was a placeholder name. If you checked before you sent your email, |
| 10 |
>> you would see that we had settled on eudev. |
| 11 |
> |
| 12 |
> The name change still doesn't make it any less "entertaining" :) |
| 13 |
> |
| 14 |
> What does the "e" stand for? |
| 15 |
|
| 16 |
That is a common question. Someone associated with Canonical suggested |
| 17 |
that e stand for embedded. Others consider the "eu" prefix to be the |
| 18 |
greek root for "true". Honestly, we don't care. It is just a name. |
| 19 |
|
| 20 |
>>> But, along those lines, what is the goal of the fork? What are you |
| 21 |
>>> trying to attempt to do with a fork of udev that could not be |
| 22 |
>>> accomplished by: |
| 23 |
>>> - getting patches approved upstream |
| 24 |
>>> or: |
| 25 |
>>> - keeping a simple set of patches outside of the upstream tree and |
| 26 |
>>> applying them to each release |
| 27 |
>> |
| 28 |
>> The goal is to replace systemd as upstream for Gentoo Linux, its |
| 29 |
>> derivatives and any distribution not related to RedHat. |
| 30 |
> |
| 31 |
> Wait, really? You want to replace systemd? Then why are you starting |
| 32 |
> at udev and not systemd? |
| 33 |
> |
| 34 |
> What is wrong with systemd that it requires a fork? All other distros |
| 35 |
> seem to be participating in the development process of systemd quite |
| 36 |
> well, what is keeping Gentoo developers from also doing the same? |
| 37 |
> |
| 38 |
> What are your goals, specifically, in detail. |
| 39 |
|
| 40 |
Is there any way that the answer to your inquiry would result in a |
| 41 |
productive conversation where you would not attempt to dictate what we do? |
| 42 |
|
| 43 |
>>> I understand the bizarre need of some people to want to build the udev |
| 44 |
>>> binary without the build-time dependencies that systemd requires, but |
| 45 |
>>> surely that is a set of simple Makefile patches, right? And is |
| 46 |
>>> something that small really worth ripping tons of code out of a working |
| 47 |
>>> udev, causing major regressions on people's boxes (and yes, it is a |
| 48 |
>>> regression to slow my boot time down and cause hundreds of more |
| 49 |
>>> processes to be spawned before booting is finished.) |
| 50 |
>> |
| 51 |
>> See the following: |
| 52 |
>> |
| 53 |
>> https://github.com/gentoo/eudev/issues/3 |
| 54 |
> |
| 55 |
> You moved from an explicit to an implicit dependency. It's not |
| 56 |
> inspiring any sense of confidence from me that there is an understanding |
| 57 |
> of how things work here. |
| 58 |
> |
| 59 |
> Seriously, the codebase you are working with isn't that large, or |
| 60 |
> complex, at all. To go rip stuff out, only to want to add it back in |
| 61 |
> later, wastes time, causes bugs, and goes against _any_ software |
| 62 |
> methodology that I know of. |
| 63 |
|
| 64 |
I can say the same about the manner in which these changes were |
| 65 |
introduced. Ripping them out to get the codebase back into a state from |
| 66 |
which we are comfortable moving forward is the only sane way of dealing |
| 67 |
with them. |
Archives