From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KTgMd-00026E-R8 for mharc-grub-devel@gnu.org; Thu, 14 Aug 2008 13:11:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTgMc-00025u-RO for grub-devel@gnu.org; Thu, 14 Aug 2008 13:11:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTgMc-00025c-AS for grub-devel@gnu.org; Thu, 14 Aug 2008 13:11:54 -0400 Received: from [199.232.76.173] (port=58919 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTgMc-00025V-4z for grub-devel@gnu.org; Thu, 14 Aug 2008 13:11:54 -0400 Received: from smtp-vbr1.xs4all.nl ([194.109.24.21]:3693) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTgMb-00074w-RN for grub-devel@gnu.org; Thu, 14 Aug 2008 13:11:54 -0400 Received: from localhost.localdomain (249-174.surfsnel.dsl.internl.net [145.99.174.249]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id m7EHBqDZ069101 for ; Thu, 14 Aug 2008 19:11:52 +0200 (CEST) (envelope-from mgerards@xs4all.nl) From: Marco Gerards To: The development of GRUB 2 References: <1217806150.9634.24.camel@localhost> <87iqug33m9.fsf@xs4all.nl> <1217891426.15145.38.camel@localhost> <87vdyfem5k.fsf@xs4all.nl> <1217954381.14674.31.camel@localhost> <1218296029.20937.10.camel@localhost> <87k5el9q99.fsf@xs4all.nl> <1218629785.8757.30.camel@localhost> <20080813130022.GB26618@thorin> <1218637704.8757.60.camel@localhost> <20080813151406.GA31203@thorin> <873al83o1m.fsf@xs4all.nl> <1218667095.8757.111.camel@localhost> Mail-Copies-To: mgerards@xs4all.nl Date: Thu, 14 Aug 2008 19:15:37 +0200 In-Reply-To: <1218667095.8757.111.camel@localhost> (Javier =?iso-8859-1?Q?Mart=EDn's?= message of "Thu, 14 Aug 2008 00:38:15 +0200") Message-ID: <87d4kb4ix2.fsf@xs4all.nl> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by XS4ALL Virus Scanner X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 Subject: Re: [PATCH] Drivemap module X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:11:55 -0000 Javier Mart=EDn 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 ker= nel 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 significan= tly. >> > >> > If the kernel interfaces are not extensible enough, you could try to r= eadjust >> > them for your needs. This approach works well most of the time (altho= ugh I >> > haven't studied this particular problem in detail). >>=20 >> 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. >>=20 >> 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