grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Drivemap module


From: Javier Martín
Subject: Re: [PATCH] Drivemap module
Date: Fri, 15 Aug 2008 00:17:26 +0200

El jue, 14-08-2008 a las 19:15 +0200, Marco Gerards escribió:
> Javier Martín <address@hidden> 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.
I don't imply you're a bad person or anything like that, sorry if it
seemed so.  By the way, I searched the whole thread of "[PATCH] drivemap
module" (starting in july 4-20) and the only instances in which
"separate", "separately", "split" or similar words are related to
phrases like "put the return on a separate line" or "split these
declarations" - even though I _do_ remember you telling me something
like what you say.

I have actually taken the time to re-read all three threads related to
drivemap [0][1][2] and the main opposition (from Vesa) was due to what
the boot command would do if one of the hooks with abort_on_error set
failed and the abort_on_error bit itself.  Nothing _fundamental_ about
the hook system.  The only other objection has surfaced recently (from
Robert) and is about the size such system would add to kernel - which
mostly depends on the implementation of the hook system (single variable
vs. array vs. linked list, for example), not the interface.  
> 
> 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.
(kneels on the floor japanese-teen-style) That is true and completely my
fault: I was stubbornly trying to convince you to change a big part of
the coding style without thinking that conventions are there for a
reason. I apologize for all the headaches I may have caused.
> 
> 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.
True, but the list is public and we can't be blamed if others are not
interested in parts of the patch. Besides, even though I've shown that
the "strong opinions" of Vesa and Robert did not affect any fundamental
part of the hook system, I _could_ split it from drivemap and put it up
for discussion on a separate thread.
> 
> 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.
It _is_ appreciated: if it weren't for you, this patch would have been
lost in the blue long ago, just because no-one would bother to look at
it.  Besides, if you don't feed the trolls (me?), I'll have to go back
to Wikipedia, where my 42 sockpuppets have already been banned! ^^
Seriously, though, I don't mean to be trollish at all, nor to bludgeon
others into submission - that's just politics...

-Habbit


[0] http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00153.html
[1] http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00053.html
[2] http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00095.html

> 
> --
> Marco
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

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