Re: [PATCH v21 001/100] eclone (1/11): Factor out code to allocate pidmap page

On Sat, May 01, 2010 at 03:10:22PM -0700, David Miller wrote:
NO WAY, there is no way in the world you should post 100 patches
at a time to any mailing list, especially those at vger.kernel.org
that have thousands upon thousands of subscribers.

I am sorry we concluded that sending these 100 patches at once was a
good idea. I will try, again, to find ways to divide the
set up into more manageable pieces. Regardless of how that goes
the whole set will not be submitted to LKML/vger all at once in the
future.

If anyone would like to offer more specific constructive suggestions
on subdividing the patches I'd be happy to try them.

That said, for anyone who's curious, we faced a few dilemmas which
pointed us down the wrong path here.

http://lkml.org/lkml/2010/3/1/422

Specifically the last part is rather hard to misinterpret:

"I'd suggest waiting until very shortly after 2.6.34-rc1 then please
send all the patches onto the list and let's get to work."

(ok, it's not shortly after 2.6.34-rc1 -- we were asked to reorganize
the code and we did...)

But even if one decides to ignore the common sense interpretation of
Andrew's reply there was more:

Standard procedure is to post to LKML when pushing patches upstream.

We were asked to create a useful implementation of checkpoint/restart
yet when we tried to submit a digestable piece we were told that
submitting it by itself was pointless (eclone). The rest of the code
was even more checkpoint/restart-specific so the same logic seemed to
apply.

We have public git trees and used the containers@ mailing list to post
patches for review but rarely received outside feedback on patches
there. Not even requests to divide the set.

So clearly we needed to post to relevant external lists and
reviewers. We tried that earlier and received complaints that lists
hadn't been Cc'd on some of the patches (e.g. fsdevel). So clearly we
needed to expand the Cc list for v21.

We looked at dividing the set but it always came down to trimming
functionality -- this conflicted with the "useful implementation"
we were asked for.

In summary: We've been given a fair number of conflicting instructions
and we failed to find the right balance in following them.

Post only small, well contained, sets of patches at a time. At most
10 or so in one go.

We've tried to keep the individual patches small and reviewable. That
has the opposite effect on patch count unfortunately.


Do you realize how much mail traffic you generate by posting so many
patches at one time, and how unlikely it is for anyone to actually
sift through and review your patches after you've spammed them by
posting so many at one time?

A second infraction and I will have no choice but to block you at the
SMTP level at vger.kernel.org so please do not do it again.

We will not post nearly this many at once again.

I'm thinking we'll just provide URLs to git trees or quilt series
if subdividing is impossible and/or anyone needs wider context than
the 10 or so we post at a time.

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

Relevant Pages

  • Re: Spreadsheet of all MS security patches
    ... > I'm trying to compile lists of various patches I need to ... > apply for different customer systems I administer. ... > patches evaluating them is getting overwhelming. ... protecting his/her 1000+ MS servers using the results of a single tool. ...
    (microsoft.public.security)
  • Re: new FreeBSD-webpage
    ... > Ports) disappeared from the front page. ... Please provide patches for the CSS if the fixed width stuff bothers ... I fix it by adding lots of news items whenever I can think of one. ... been made within hours of them first being brought up on the lists. ...
    (freebsd-stable)
  • Re: [patch] x86, voyager: fix ioremap_nocache()
    ... more patches get more review by more specialists. ... But when I have time I skim over patches on linux-kernel, ... not only to a gazillion different lists. ...
    (Linux-Kernel)
  • Re: Comparing lists of patches
    ... >>What it does is, it keeps a list of patches that were on the system, and ... >>then basically computes a Cartesian crossproduct between the two lists. ... fgrep seems to be the answer. ... Dump both lists of patches to temp files, ...
    (comp.sys.sun.admin)
  • Re: [BUG?] 2.6.25-rc[23]-mm1 cgroup list corruption under load with VM Scalability patches
    ... I can't say for sure that our patches aren't causing this, ... splitlru+noreclaim patches to hit the problem. ... I looked in the mailing lists and found one other thread related to ... load on my 16 cpu ia64 platform. ...
    (Linux-Kernel)