Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08
Date: Wed, 25 Apr 2012 06:04:15
Message-Id: 20120425033445.GA7542@linux1
In Reply to: Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08 by Rich Freeman
On Tue, Apr 24, 2012 at 08:20:10PM -0400, Rich Freeman wrote:
> 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 > involvement.
Everybody has to live with this stuff couldn't be more true. We are talking about changes in the linux world that are coming from outside of gentoo.
> 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.
Like I said above, it isn't just the udev maintainers. We aren't talking about changes to udev. we are talking about changes to the entire linux ecosystem.
> 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 > ebuilds.
I too am definitely a proponent of choice. However, I don't feel that the choice of having /usr on a separate file system without using an initramfs is a practical one to offer; especially with the /usr merge coming down the pipe. I didn't like making the change either. But, after some thought and reading the arguments supporting it, I did, because I can see how it will make things easier in the future. Building an initramfs that works was simple on my system using genkernel; the tracker for udev points to the bug that shows how to do it. Once the documentation for setting up an initramfs is in place which will be done before >=udev-182 is stabilized, all you will need to do is set one up, then you can just enjoy the ride. We will not start the /usr merge before this udev is stabilized. William