[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1272472405.18228.16.camel@Joe-Laptop.home>
Date: Wed, 28 Apr 2010 09:33:25 -0700
From: Joe Perches <joe@...ches.com>
To: Valdis.Kletnieks@...edu
Cc: Greg KH <gregkh@...e.de>, Greg KH <greg@...ah.com>,
devel@...verdev.osuosl.org, Scott Smedley <ss@....gov.au>,
Jason Baldus <jason.baldus@...il.com>,
linux-kernel@...r.kernel.org,
Harley Sweeten <hsweeten@...ionengravers.com>,
Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH 1/3] drivers/staging/dt3155: Integrate 3 badly styled
files into 1 clean file
On Wed, 2010-04-28 at 12:12 -0400, Valdis.Kletnieks@...edu wrote:
> On Tue, 27 Apr 2010 23:00:30 PDT, Joe Perches said:
> > On Tue, 2010-04-27 at 22:52 -0700, Greg KH wrote:
> > > > I seem to be learning that you little taste.
> > > -ENOPARSE
> >
> > Choosing competing patches based on date received
> > order not quality is poor taste.
>
> So you're saying when Greg gets a somewhat ugly but passable patch 2 weeks ago,
> he's supposed to *just know* that you'll be submitting a possibly better one 2
> weeks later and wait for it to show up?
No, I'm saying that when Greg gets multiple
patches for the same module and doesn't act on
any of them for several weeks, (in this case
one 6 weeks ago, and two others 4 weeks ago)
he should select the better patches, not just
apply the first one in chronological order.
> How is that supposed to work in reality?
Apparently slowly and fitfully.
If the cycle time was shorter and the feedback
better, it would be less of an issue.
Greg has explained he was unavailable to look at
patches for an extended period. Unfortunately
that extended period was immediately after a talk
Greg gave and an article Greg authored designed
to generate new contributor patches for staging.
The talk and articled worked.
Many new individuals followed his template format
producing cleanup patches, some good, some less
good. Few if any of those patches received feedback
from Greg or had notice of patch status for that
extended period.
It would be better if the backlog of patches were
order sifted by quality than chronology.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists