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

[Greg KH <gregkh@gentoo.org>]

On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote:
> > 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 am afraid that I have to disappoint you. If we were using the
> waterfall model, I could outline some very nice long term goals for you,
> but we are doing AGILE development, so long term goals have not been
> well defined. Some short term goals have been defined, but I imagine
> that you are already familiar with them. I suggest asking again after
> our first tag.

I'll ignore the fact that project goals have nothing to do with
waterfall or agile, and ask, what are your short-term goals?

Why is this an "official" Gentoo project without this being discussed in
an open manner?

> A consequence of being open source means that everyone can see what we
> do, so people are able to send us their opinions on things that have not
> been officially announced, much like this project.

Given that the Gentoo Foundation is claiming copyright on this project
now, not announcing it seems a bit rude to the rest of us who make up
this foundation, don't you think?

That's not very open :(

> >>>>> 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
> 
> Having a builtin is a good idea, but the implementation as a mandatory
> dependency on kmod is not. The plan is to reintroduce it as an optional
> dependency, so that distributions (and Gentoo users) that do not want it
> can avoid it. None of us want to force dependencies on others and there
> is no need for this one.

You do realize that you didn't really drop the dependency at all, right?

> With that said, Linux distributions are victims of people continually
> trying to reinvent the wheel with no formal planning.

Huh?  Really?  It's as if you think we all are just throwing stuff
against the wall and seeing what sticks?  We aren't responding to real
users, customers, research, history, and competitors?  Your dismissal of
the people who create the system you are using seems pretty bold.

> At some point, someone has to enforce a form of structure where
> further change occurs in a well defined manner and change because we
> can is rejected as being pointless. That is what we want and that is
> what we feel that our users want.

Ok, what is that structure you are wishing were present?  What problems
do you have with systemd on a technical level that are not being
addressed?  What technical problems with udev do you have that caused
this to be forked?  What problems are you wishing to solve, and what
goals do you have by doing all of this?

Have you studied the problem area for booting, process monitoring,
system isolation, device creation and notification, persistant naming,
multiple users with multiple displays, and the like, and found that
Linux is lacking in this area?  If so, I would love to learn more, as I
want Linux, and Gentoo, to succeed.  Without knowing the problems you
are having, there's no way anyone will ever change.

thanks,

greg k-h