On Tue, Apr 24, 2012 at 6:26 PM, William Hubbs <email@example.com> wrote:
> Honestly, I agree with you. I am a udev maintainer myself, and the udev
> maintainers did not bring this issue to council. More than that, no one,
> that I recall, discussed any ramifications of this vote with any udev
> maintainers before bringing it to council.
> The ramifications, as I said in my previous email, are not just udev
> related (see the section in my previous email about the /usr merge).
> Once we start implementing the /usr merge, it will not matter whether
> you use udev or not, you will have to have an initramfs if your /usr is
I have mixed feelings on this.
The fact that the ramifications are not just udev-related tends to
point to the fact that this shouldn't simply be up to the udev team.
These are big changes for Gentoo, and there is a great deal of
controversy across the Linux world resulting from them (the
Shuttleworth vs Pottering debate being the latest iteration of this).
Everybody has to live with this stuff, which points to council
On the other hand, somebody has to maintain all this code, so having a
bunch of non-udev-maintainers telling them what to do is not a great
thing either. Worst case you end up with a bunch of frustrated people
giving up on it, which leaves us much worse off. If you are paying
your staff you can tell them what to do, but with volunteers you need
to be more "inspirational" in your leadership. If the udev team
thinks this is the way the wind is blowing then either more people
need to step up and help them maintain more configurability, or we
need to just work with them to make the ride as smooth as we can. I
don't think anybody wants to see needless end-user pain here in any
case, and as far as I can tell the udev maintainers are quite willing
to work with other projects (genkernel, dracut, docs, etc) as needed.
Lots of people have pointed out alternative options, and I've always
been a proponent of "Gentoo is about choice." However, if we want a
choice to be available people do need to step up and make those
choices available. Volunteer distros don't work well when people tell
others how to maintain their code. We struggle enough with basic
quality control sometimes, and I think most of us can admit it when we
make a mistake in these areas (if for no reason than out of pride in
our work). To ask developers to build to somebody else's design in a
volunteer organization may be asking a bit much.
I think the best we can do is look for opportunities to give people
choices when they're practical, and when people are willing to pitch
in and maintain their side of the interfaces. You don't even have to
be a Gentoo developer to do that - just look at OpenRC/etc - get an
account on github, do good work, and ask some developer to commit your