All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Drivemap module
Date: Thu, 14 Aug 2008 19:15:37 +0200	[thread overview]
Message-ID: <87d4kb4ix2.fsf@xs4all.nl> (raw)
In-Reply-To: <1218667095.8757.111.camel@localhost> (Javier Martín's message of "Thu, 14 Aug 2008 00:38:15 +0200")

Javier Martín <lordhabbit@gmail.com> writes:

> Ok, making a mixup reply...

Please don't.  Unless you do not like it that your mails go unread.

>> > Having a small kernel is highly desireable for most users.  If the kernel is
>> > too big, it won't fit and then either we have to use blocklists (which are
>> > unreliable), or we have to abort the install.
>> >
>> > Please, try to find a way that doesn't increase kernel size significantly.
>> >
>> > If the kernel interfaces are not extensible enough, you could try to readjust
>> > them for your needs.  This approach works well most of the time (although I
>> > haven't studied this particular problem in detail).
>> 
>> Like discussed before.  Bring up such modifications like hooks up in a
>> *separate* thread.  I already said that not everyone reads this
>> discussion.  I will not accept a patch that changes the kernel if it
>> is part of a bigger patch that not many people read.
>> 
>> Please don't discuss this over with Robert and me, you know that it
>> was pointed out that this has to be a patch in a separate thread.
>> Furthermore, this is a way to get some feedback from Bean who wants
>> something similar, IIRC.
>
> I know I will be regretting saying this, but it is _very_ rude to review
> some five versions of the patch, spotting mostly coding-style errors on
> each, and then, on version 8, tell me that "you won't accept a patch
> that contains blah" (with "blah" being essential for the patch to work).
> Quite the proverbial slap in the face to me.

I did NOT say that your patch will not be accepted.  In one of the
earlier reviews (perhaps even the first) I mentioned that certain
parts should be reviewed separately.  It is a slap in the face that
you imply I am a bad person when I repeat that you need to bring up
some issues *separately*.  I would consider it bad style from me
towards other developers to change code they might have a strong
opinion on.

And you can say what you want, but if you are stubborn enough to
ignore what I say in the reviews, you shouldn't be surprised if I
didn't change my opinion in the next review and still ask you to
change something.  In fact, it is rude just to send in a new patch
while you did not take the review seriously.  There are a lot of
projects that reject patches on beforehand if you didn't at least
bother to get familiar with their coding styles.

Furthermore, I reviewed your patch mainly because I care, not because
I am the foremost expert in BIOS disks.  It's for the best if other
people can look at specific parts of your patch, especially if it
changes the kernel.

Perhaps you do not notice how many time I spent on reviewing patches
on this list lately.  Anyways, if it is not appreciated, I will leave
the reviews to other people.  But I simply will reject all code I do
not like without actually bothering to explain why.  I rather spend my
time on coding instead of feeding trolls.

--
Marco




  reply	other threads:[~2008-08-14 17:11 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-04  2:12 [PATCH] Drivemap module Javier Martín
2008-07-05 11:04 ` Marco Gerards
2008-07-16 15:39   ` Javier Martín
2008-07-20 19:40 ` Marco Gerards
2008-07-21  0:55   ` Javier Martín
2008-07-21 11:07     ` Javier Martín
2008-07-22 21:32     ` Robert Millan
2008-07-31 19:01     ` Marco Gerards
2008-08-03 23:29       ` Javier Martín
2008-08-04 20:51         ` Marco Gerards
2008-08-04 23:10           ` Javier Martín
2008-08-05  0:50             ` Isaac Dupree
2008-08-05  2:38               ` Javier Martín
2008-08-05 11:31                 ` Marco Gerards
2008-08-05 11:23             ` Marco Gerards
2008-08-05 17:18               ` Colin D Bennett
2008-08-05 11:28             ` Marco Gerards
2008-08-05 16:39               ` Javier Martín
2008-08-09 15:33                 ` Javier Martín
2008-08-13 10:13                   ` Marco Gerards
2008-08-13 12:16                     ` Javier Martín
2008-08-13 13:00                       ` Robert Millan
2008-08-13 14:28                         ` Javier Martín
2008-08-13 14:51                           ` Marco Gerards
2008-08-13 15:14                           ` Robert Millan
2008-08-13 15:57                             ` Marco Gerards
2008-08-13 22:38                               ` Javier Martín
2008-08-14 17:15                                 ` Marco Gerards [this message]
2008-08-14 22:17                                   ` Javier Martín
2008-08-13 13:01                       ` Robert Millan
2008-08-05 17:15             ` Colin D Bennett
  -- strict thread matches above, loose matches on Subject: below --
2008-08-08 13:43 Viswesh S
2008-08-07 12:15 Viswesh S
2008-08-06 14:43 Viswesh S
2008-08-06 17:31 ` Javier Martín
2008-08-08 13:20   ` Felix Zielcke
2008-06-10 20:09 Javier Martín
2008-06-10 20:23 ` Vesa Jääskeläinen
2008-06-10 21:31   ` Javier Martín
2008-06-12 20:31     ` Pavel Roskin
2008-06-12 22:43       ` Javier Martín
2008-06-12 22:58         ` Colin D Bennett
2008-06-13  1:00           ` Pavel Roskin
2008-06-13  4:09             ` Colin D Bennett
2008-06-13  1:37         ` Pavel Roskin
2008-06-13  2:29           ` Javier Martín
2008-06-11 14:44 ` Marco Gerards

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=87d4kb4ix2.fsf@xs4all.nl \
    --to=mgerards@xs4all.nl \
    --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.