[gentoo-dev] Re: eudev project announcement

[Duncan]

Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted:

> [Udev-systemd has] essentially announced ahead of time that most bugs
> from non-systemd users would be closed with WONTFIX.

Agreed, to this point.

> Actually, for political reasons, I hope that eudev does submit a bunch
> bugs+patches, and gets them rejected.  Then whenever anyone complains
> about not sharing code, show them a bunch of WONTFIX emails from
> systemd/udev maintainers.

This attitude is and the described events would be... unfortunate.

For the reasons you list, I don't believe people should be /surprised/ if 
many such bugs+patches are rejected after submission, but that wouldn't 
make it any less unfortunate, and IMO, hoping they DO get rejected is the 
wrong attitude to have.

The best possible outcome, IMO, would be that the eudev (and any other 
udev replacement projects) eventually work themselves out of a job.  
Ideally, the very existence of these projects will trigger a rethink on 
the part of the udev folks, causing the reasons for the fork to disappear 
over time.  Ideally, with effort and compromise on NIH and similar 
attitudes on /both/ sides, differences can be put aside and udev (whether 
it remains developed under the systemd umbrella or not) can once again be 
the unifying influence its authors claim to intend.

To some extent the hubbub has already appeared to trigger incremental 
walkbacks and/or the exploration of third ways.  The kernel's recent 
addition of its own module loading code, endorsed by the udev folks, is 
one such third way development.  Perhaps I'm reading my own viewpoint 
into things, but it seems from here anyway, that the systemd-udev side 
rhetoric on initr*-less support for a separate /usr is... less 
strident... than it was.  And kmod was initially required by new udev, 
but is now optional.  I'd call all of these good developments... that may 
well have never occurred had pushback including but not limited to the 
eudev project hadn't occurred.

Ideally, then, the need for eudev as an actually installed systemd-udev 
alternative will disappear even as eudev is being born.  However, that's 
no argument yet for termination of the project and in fact is arguably 
the reverse, given systemd and now udev's history of ignoring feedback 
from those it's riding roughshod over, as long as people continue to LET 
it ride roughshod over them.  The existence of the eudev project, 
therefore, may continue to be necessary, if only to provide a practical 
udev alternative such that udev itself moderates to the point that the 
alternative need not be actually used on a system.

But at least there's an alternative now, so that regardless of whether 
systemd-udev moderates or not, people aren't left without recourse.  
Hopefully that moderation occurs and the alternatives can ultimately be 
merged back in, but there's recourse now, so people are no longer 
actually dependent on udev-systemd's moderation.

Which way that takes both udev-systemd and eudev remains to be seen, but 
I'd /still/ consider it /unfortunate/ if those bugs+patches do appear and 
get WONTFIXed, thus, certainly I hope they appear, but just as certainly, 
one can HOPE they get resolved/merged, *NOT* resolved/WONTFIXed.

Time will tell.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman