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?

> > 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.

> > 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.

confused,

greg k-h

Reply via email to