Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 04:42 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:
>
> > >         pata_efar: MWDMA0 is unsupported
> >
> > skipped, pending discussion (just sent email)
>
> The discussion was there, you were not especially interested
> (http://lkml.org/lkml/2009/11/26/343).

I reviewed the discussion before adding an email to that thread.


> > >         pata_hpt3x2n: fix overclocked MWDMA0 timing
> >
> > skipped, pending discussion (just sent email)
>
> ditto (http://lkml.org/lkml/2009/11/27/257).

I reviewed the discussion before adding an email to that thread.


> There were no complains so I'm pretty sure Sergei was fine with it.

It was unclear, hence I sent email for clarification.


> > >         pata_hpt3x3: Power Management fix
> >
> > applied, on a hope and a prayer (did not see this posted to mailing
> > list?).  It looks correct to me.
>
> I prefer sticking to technical facts. ;)
>
> Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321

Whoops, I indeed missed this one.


> > >         pata_via: clear UDMA transfer mode bit for PIO and MWDMA
> >
> > applied -- even though Alan's comment was correct.  It is standard
> > kernel practice to place cosmetic changes into their own patches,
> > because it is standard kernel practice to break up logically distinct
> > changes.
>
> We are talking about:
>
>   pata_via.c |   19 +++++++++++++------
>   1 file changed, 13 insertions(+), 6 deletions(-)
>
> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> is clearly documented in the patch description.
>
>
> Do people really wonder why I find upstream to be too much hassle to
> deal with?

The thousand other kernel developers seem to be able to split up their 
patches, separating out cosmetic changes from functional ones.  It has 
clear engineering benefits, and has been standard practice for a decade 
or more.

Why is it such an imposition for your patches to look like everyone 
else's?  And by "everyone", I mean all other kernel developers, not just 
other ATA developers.

You seem to consider standard kernel practice a hassle.  Separating out 
cosmetic changes is not only a libata practice, it is the norm for the 
entire kernel.

	Jeff


--
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/