Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH <gregkh@gentoo.org>]

On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote:
> On 11/17/2012 11:19 PM, Greg KH wrote:
> > 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?
> 
> That is a common question. Someone associated with Canonical suggested
> that e stand for embedded. Others consider the "eu" prefix to be the
> greek root for "true". Honestly, we don't care. It is just a name.

I wouldn't pick "embedded" as the embedded world is now using systemd as
it meets their requirements much better than anything else :)

> >>> 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.
> 
> Is there any way that the answer to your inquiry would result in a
> productive conversation where you would not attempt to dictate what we do?

The only thing I'm "telling" anyone to do is to fix the copyright mess
they created, as it is a legal liability for the Gentoo Foundation,
which I care about.  That HAS to be resolved.

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