LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: jos poortvliet <jos@mijnkamer.nl>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Chuck Ebbert <cebbert@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	ck@vds.kolivas.org, Con Kolivas <kernel@kolivas.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [ck] Re: Swap prefetch merge plans
Date: Sat, 10 Feb 2007 17:12:51 +0100	[thread overview]
Message-ID: <200702101712.55855.jos@mijnkamer.nl> (raw)
In-Reply-To: <20070209155410.59e0cf4b.randy.dunlap@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Op Saturday 10 February 2007, schreef Randy Dunlap:
> On Fri, 09 Feb 2007 18:35:51 -0500 Chuck Ebbert wrote:
> > Andrew Morton wrote:
> > > I have an email sitting in my drafts folder stating that I'll no longer
> > > accept any features unless they've been publically reviewed in detail
> > > and run-time tested by a third party.  The idea being to force people
> > > to spend more time reviewing and testing each other's stuff and less
> > > time writing new stuff.  Maybe on a sufficiently gloomy day I'll
> > > actually send it.
> >
> > /me sneaks into Andrew's office and sends it out.
>
> Thanks.  8)

Well, is it smart? I mean, it's not stupid of course, but it has its 
disadvantages which Andrew already mentioned. Less time for writing new 
stuff. So it is a tradeoff, most likely the reason why he didn't send it yet. 

What are the sideeffects of this? Does it repel people? Or controversely, does 
it bring new people in, who are asked by others to do a little review? 

Does it lead to better documented and commented code, to help the review 
process? Does it lead to worse reviews? Does it stiffle innovation, or, as 
more ppl work on one patch, does it stimulate it? Will people start to 
cooperate more, or will they argue and fight when someone refuses to review 
patches?

Anyway, you can't know these in advance, and watching what it does is the only 
way to find out. Its Andrew's call, either way.

Days should't be gloomy, but if they do, trying new things is the only way to 
find a solution. The growing amount of people workin on the kernel and the 
increasing demands from the users force the kernel community to evolve, and 
central figures like Andrew and Linus play a big role in this. I think you 
guys have done a great job until now, and I trust you can keep it that way.

Jos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2007-02-10 16:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200702091038.37143.kernel@kolivas.org>
     [not found] ` <200702092054.10232.ocilent1@gmail.com>
     [not found]   ` <200702092321.20615.kernel@kolivas.org>
2007-02-09 13:13     ` jos poortvliet
2007-02-09 13:22       ` Con Kolivas
2007-02-09 14:00         ` jos poortvliet
2007-02-09 13:56       ` Con Kolivas
2007-02-09 20:30       ` Andrew Morton
2007-02-09 20:50         ` Con Kolivas
2007-02-09 22:49           ` Con Kolivas
2007-02-09 23:35         ` [ck] " Chuck Ebbert
2007-02-09 23:54           ` Randy Dunlap
2007-02-10 16:12             ` jos poortvliet [this message]

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=200702101712.55855.jos@mijnkamer.nl \
    --to=jos@mijnkamer.nl \
    --cc=akpm@linux-foundation.org \
    --cc=cebbert@redhat.com \
    --cc=ck@vds.kolivas.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --subject='Re: [ck] Re: Swap prefetch merge plans' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).