lkml.org 
[lkml]   [2005]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [uml-devel] Re: [RFC] [patch 0/39] remap_file_pages protection support, try 2

* David S. Miller <davem@davemloft.net> wrote:

> From: Blaisorblade <blaisorblade@yahoo.it>
> Date: Fri, 12 Aug 2005 20:56:11 +0200
>
> > However, I sent the initial tarball containing all them, so I hope
> > that will be useful.
>
> So not only did you spam the list with 40 patch postings, you sent a
> second copy of everything as a tarball attachment as well. That's
> even worse.
>
> Please do not abuse the list server in this way, it is a resource that
> is not just your's, but rather one which has to be shared amongst all
> folks doing kernel development.

while i agree that 40 patches is not common, i'd like to point out that
Paolo has sent 40 very nicely split up patches instead of one
unreviewable monolithic patch, which are the encouraged format for
kernel changes. I havent seen any hard limit mentioned for patch-bombs
on lkml before - and i've seen much larger patchbombs going to lkml as
well, without any followup chastising of the submitter. E.g.:

Subject: [0/48] Suspend2 2.1.9.8 for 2.6.12

So if there needs to be some limit, it might be worth defining some
actual hard limit for this.

But the more important point is that given how complex the VM, and in
particular sys_remap_file_pages_prot() is, i'm personally much more
happy about the work having been submitted in a split-up way than i am
unhappy about the bombing!

Paolo has actually worked alot on this, which resulted in 40 real, new
patches, so i couldnt think of any better way to present this work for
review. Had he posted some link it would not be individually reviewable.
(nor could the patch components be picked up by search utilities in that
case - i frequently search lkml for patches, but naturally i dont
traverse links referenced in them.) So i think we should rather be happy
about the 40-patch progress that Paolo has made to Linux, than be
unhappy about this intense work's effect on our infrastructure.

In other words, we should not be worried about the number of real
changes submitted to lkml, and we should only hope for that number to
increase, and we should encourage people to do it! Paolo did this in 2
weeks, so it's not like he has sent changes accumulated over a long time
in a patch-bomb. It was real, cutting-edge work very relevant to lkml,
which work i believe Paolo didnt have much choice submitting in any
other sensible and reviewable form.

(i think i agree that maybe the tarball should not have been sent - but
even that one was within the usual size limits and other people send
tarballs frequently too.)

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-14 04:06    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site