grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Split of the normal mode


From: Robert Millan
Subject: Re: [PATCH] Split of the normal mode
Date: Wed, 1 Apr 2009 15:19:00 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]