On Sun, Mar 29, 2009 at 07:09:56PM +0900, Yoshinori K. Okuji wrote: > > Indeed. I don't understand this tendency about splitting modules at all. What > is the motivation behind? What is the real benefit for the user? > > From my point of view, it is wrong to force the user to manually load > modules, > generally. This includes writing "insmod" in config files. Look at Linux. It > is quite rare to execute insmod or modprobe directly. Most of the time, > modules are loaded on demand. This is the user-friendliness.
I agree with your point. It should be noted, though, that in some of these situations grub-mkconfig compensates that by generating "insmod xxx" statements on-demand (a good example would be that "insmod lvm" can be generated by prepare_grub_to_access_device). > FYI, I am planning to make a full review of recent changes (i.e. all changes > made after I stopped reviewing every patch), and trash/revert/rewrite/blame > everything I don't like. Changes made for no good reason must be all > reverted. > > In brief, I take back the leadership of this project for general directions. > For some subsystems (e.g. the coreboot support), I continue leaving the > responsibility to those who know better or are more active. Once the current > code is reviewed and fixed (at some degree), I will make a new release. > > Any objection? GRUB is in dire need of an active project lead. I'm happy to see what you plan to take back on that role. Over the last few months, I tried to cover up for some of the work you and Marco weren't doing, like processing the patches nobody wanted to look at, or requesting copyright assignments. TBH, it wasn't a pleasant task, and if you'll be doing it from now on, it's a relief for me. As for reverting changes, I acknowledge you have the authority to do that, but it would be very harmful to the project if all sort of things started being reverted with no proper discussion. When I say harmful, I mean that some people might end up sticking with their own private trees, which later can't easily be merged. It's very important to build consensus on such things. So my suggestion is that you bring up discussion on which things you plan to revert. If we can't reach consensus, you have the authority to impose your own view, but please try to find consensus, and be open to arguments that might convince your POV. To summarize, I approve of your decision, but I'd be very disappointed if all this just happens so you can revert a bunch of stuff and inmediately afterwards we're left with no active maintainer again. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
