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
