All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Split of the normal mode
Date: Wed, 1 Apr 2009 15:19:00 +0200	[thread overview]
Message-ID: <20090401131900.GD27958@thorin> (raw)
In-Reply-To: <200903291909.56201.okuji@enbug.org>

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



  parent reply	other threads:[~2009-04-01 13:19 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-29  9:25 [PATCH] Split of the normal mode Bean
2009-03-29  9:40 ` Vesa Jääskeläinen
2009-03-29 10:09   ` Yoshinori K. Okuji
2009-03-29 10:43     ` phcoder
2009-03-29 10:53       ` Vesa Jääskeläinen
2009-03-29 11:33         ` phcoder
2009-03-29 11:51           ` Yoshinori K. Okuji
2009-03-29 12:09             ` Bean
2009-03-29 13:10               ` Yoshinori K. Okuji
2009-03-29 13:59                 ` Bean
2009-03-29 14:20                   ` Yoshinori K. Okuji
2009-03-29 14:30                     ` Bean
2009-03-29 14:54                       ` Yoshinori K. Okuji
2009-03-29 15:17                         ` Bean
2009-03-30 15:42                           ` Yoshinori K. Okuji
2009-03-30 20:04                 ` Colin D Bennett
2009-03-31  6:11                   ` Bean
2009-03-31 15:02                     ` Colin D Bennett
2009-03-29 13:00             ` phcoder
2009-03-29 14:51               ` Yoshinori K. Okuji
2009-03-29 17:07                 ` phcoder
2009-03-29 20:35                   ` phcoder
2009-03-30 15:49                     ` Yoshinori K. Okuji
2009-03-30 15:59                       ` phcoder
2009-04-01  7:43                         ` phcoder
2009-04-01  8:07                           ` David Miller
2009-04-01  9:22                             ` phcoder
2009-04-01 14:10                               ` Yoshinori K. Okuji
2009-04-01 16:14                                 ` phcoder
2009-03-29 11:29       ` Yoshinori K. Okuji
2009-03-29 11:40         ` David Miller
2009-03-29 12:55           ` Yoshinori K. Okuji
2009-03-29 13:23             ` Vesa Jääskeläinen
2009-03-29 14:49               ` Yoshinori K. Okuji
2009-03-29 15:43                 ` Vesa Jääskeläinen
2009-03-29 20:26               ` David Miller
2009-03-29 20:24             ` David Miller
2009-03-29 20:38               ` phcoder
2009-03-30 15:43                 ` Bean
2009-03-30 16:22                   ` Yoshinori K. Okuji
2009-03-30 16:38                     ` Bean
2009-03-30 16:35                   ` Vesa Jääskeläinen
2009-03-29 11:59         ` General design (was Re: [PATCH] Split of the normal mode) phcoder
2009-03-29 10:48     ` [PATCH] Split of the normal mode Vesa Jääskeläinen
2009-03-29 11:39       ` Yoshinori K. Okuji
2009-03-29 12:17       ` Vesa Jääskeläinen
2009-04-01 13:19     ` Robert Millan [this message]
2009-04-01 14:15       ` Yoshinori K. Okuji

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090401131900.GD27958@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.