drivers/staging/dt3155: Integrate 3 badly styled files into 1 clean file
in [Kernel]
|
Prev: [PATCH][RFC] AIO: always reinitialize iocb->ki_run_list at the end of aio_run_iocb()
Next: intel_i830_chipset_flush(): local clflush() vs. global wbinvd()
From: Greg KH on 27 Apr 2010 19:10 On Mon, Mar 29, 2010 at 12:34:28AM -0700, Joe Perches wrote: > Make variables static where appropriate > Rename dt3155_<foo_with_long_names> variables to dt_<foo_tla> > to reduce code length and make more lines fit well in 80 chars > Remove now unnecessary .h files > Change indent to use tabs > Remove unused functions > Used bool more often > Checkpatch clean This is too much in one patch, sorry. It also doesn't apply due to other changes in these files (that you then remove in patch 3) from other developers. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 28 Apr 2010 01:40 On Tue, 2010-04-27 at 16:02 -0700, Greg KH wrote: > On Mon, Mar 29, 2010 at 12:34:28AM -0700, Joe Perches wrote: > > Make variables static where appropriate > > Rename dt3155_<foo_with_long_names> variables to dt_<foo_tla> > > to reduce code length and make more lines fit well in 80 chars > > Remove now unnecessary .h files > > Change indent to use tabs > > Remove unused functions > > Used bool more often > > Checkpatch clean > > This is too much in one patch, sorry. You should be more consistent. http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel Greg even said, "submit one big patch if you want" > It also doesn't apply due to > other changes in these files (that you then remove in patch 3) from > other developers. No, it doesn't apply because you chose to apply other patches before this one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 28 Apr 2010 01:50 On Tue, 2010-04-27 at 22:34 -0700, Greg KH wrote: > > No, it doesn't apply because you chose to apply other patches > > before this one. > Those patches were sent to me before yours, sorry. By like an hour. They were ugly so I cleaned them. And besides, you didn't act on them for over a month. I seem to be learning that you little taste. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 28 Apr 2010 02:10 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 28 Apr 2010 12:40
On Wed, 2010-04-28 at 12:12 -0400, Valdis.Kletnieks(a)vt.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |