Joe Perches wrote:
> On Fri, 2009-12-04 at 14:10 +0100, Brice Goglin wrote:
>> Joe Perches wrote:
>>> Only files where David Miller is the primary git-signer.
>>> wireless, wimax, ixgbe, etc are not modified.
>> What's the point? Having them at the beginning of the next line is
>> easier to read from my point of view.
>
> It's just a stupid consistency thing.
>
Brice, I've made my objection known on the LKML. Joe *agrees* that
having them on the beginning of the line is preferred. Thousands of
contributors throughout the tree agree.
This is entirely a Miller thing.
My main objection to these sweeping patches is that it makes it much
more difficult to maintain and apply patches across different versions of
the tree. We have already seen conflicts with other git maintained trees.
These patches should not be accepted to the main Linus tree.
On Sat, 2009-12-05 at 07:43 -0500, William Allen Simpson wrote:
> Joe Perches wrote:
> > On Fri, 2009-12-04 at 14:10 +0100, Brice Goglin wrote:
> >> Joe Perches wrote:
> >>> Only files where David Miller is the primary git-signer.
> >>> wireless, wimax, ixgbe, etc are not modified.
> >> What's the point? Having them at the beginning of the next line is
> >> easier to read from my point of view.
> > It's just a stupid consistency thing.
> Joe *agrees* that
> having them on the beginning of the line is preferred.
This is not true.
I prefer code that I write for myself to
use leading continuation tests.
For the Linux code, as should be obvious
from the patches I submit, I prefer to
have adherence to one predominant majority
style. I don't much care what form that
style actually takes.
> Thousands of
> contributors throughout the tree agree.
> This is entirely a Miller thing.
Nope. There have been many efforts to
help standardize on single form styles.
> My main objection to these sweeping patches is that it makes it much
> more difficult to maintain and apply patches across different versions of
> the tree.
I think you underestimate the value of
standardization and overestimate the
quantity of work to sort it out for
the -stable versions.
cheers, Joe
Joe Perches wrote, On 12/05/2009 06:50 PM:
> On Sat, 2009-12-05 at 07:43 -0500, William Allen Simpson wrote:
>> Joe Perches wrote:
>>> On Fri, 2009-12-04 at 14:10 +0100, Brice Goglin wrote:
>>>> Joe Perches wrote:
>>>>> Only files where David Miller is the primary git-signer.
>>>>> wireless, wimax, ixgbe, etc are not modified.
>>>> What's the point? Having them at the beginning of the next line is
>>>> easier to read from my point of view.
>>> It's just a stupid consistency thing.
>> Joe *agrees* that
>> having them on the beginning of the line is preferred.
>
> This is not true.
>
> I prefer code that I write for myself to
> use leading continuation tests.
>
> For the Linux code, as should be obvious
> from the patches I submit, I prefer to
> have adherence to one predominant majority
> style. I don't much care what form that
> style actually takes.
>
>> Thousands of
>> contributors throughout the tree agree.
>> This is entirely a Miller thing.
>
> Nope. There have been many efforts to
> help standardize on single form styles.
>
>> My main objection to these sweeping patches is that it makes it much
>> more difficult to maintain and apply patches across different versions of
>> the tree.
>
> I think you underestimate the value of
> standardization and overestimate the
> quantity of work to sort it out for
> the -stable versions.
Actually, technically, legally etc. (except practically) William is right:
if it's not in the CodingStyle, and not obviously wrong, it shouldn't be
forced.
Jarek P.
From: William Allen Simpson <[email protected]>
Date: Sat, 05 Dec 2009 07:43:41 -0500
> These patches should not be accepted to the main Linus tree.
You come out of nowhere as a new contributor. You have to constantly
ask about policy and other formalities wrt. kernel development.
Yet here you are telling us what should or should not go into the
tree.
You don't even know what the "merge window" is yet you seem so
confident to elicit firm declarations about code policy.
That's nothing but blind arrogance.
Nobody can take you seriously William, really.
And if you think just omitting Joe's patch is going to make your
backporting work any easier, you're mistaken.
Every release we make tons and tons of cleanups and refactorizations
all over the networking and sometimes heavily in TCP. So you're going
to run into such problems no matter whether Joe's patch goes in or
not.
And like Joe, I think you overstate how much effort is involved
in such work. Especially for the size of your patch.
And consider, how in the world do you think it is for me to have to
handle hundreds of patches per day from random people. If anyone
should get the brunt of the pain, it's me.
Yet I'm ok with it, and you should be too.
David Miller wrote:
> From: William Allen Simpson <[email protected]>
> Date: Sat, 05 Dec 2009 07:43:41 -0500
>
>> These patches should not be accepted to the main Linus tree.
>
> You come out of nowhere as a new contributor. You have to constantly
> ask about policy and other formalities wrt. kernel development.
>
Because they are not documented. Oh, and a reminder -- you've not
answered my most recent questions....
> Yet here you are telling us what should or should not go into the
> tree.
>
> You don't even know what the "merge window" is yet you seem so
That would be one of the questions (which git clone to patch against now)
that you haven't answered. Silly of me to ask practical questions.
> confident to elicit firm declarations about code policy.
>
That would be because I've ample experience coding for multiple open
source platforms. Apparently such experience isn't valued (by you).
But the fact that about 19% of the Linux code base has managed to function
for circa 18 years without this particular coding policy might be a clue!
> That's nothing but blind arrogance.
>
> Nobody can take you seriously William, really.
>
Always _such_ a delight interacting with you, and your personal attacks.
Something that *is* in Documentation/ManagementStyle at 147:
There's just a few simple rules here:
(1) don't call people d*ckheads (at least not in public)
(2) learn how to apologize when you forgot rule (1)
Joe Perches wrote:
> On Sat, 2009-12-05 at 07:43 -0500, William Allen Simpson wrote:
>> My main objection to these sweeping patches is that it makes it much
>> more difficult to maintain and apply patches across different versions of
>> the tree.
>
> I think you underestimate the value of
> standardization and overestimate the
> quantity of work to sort it out for
> the -stable versions.
>
As I mentioned to somebody in private email (having kept rough track), it
took around 9 hours this week for my 8 patch series, spread over 3 days
because of the tedium. Fix rejects, visually check patch against previous
version, compile, test -- at least 1/2 to 1 hour for each numbered patch.
Plus time to resubmit the patch series to the list again.
Of course, that was only for the initial patches already posted to the
list. I've many more -- awaiting approval for the previous set....
Eventually, I have to do the same for each supported -stable version.
Multiply by thousands of contributors.
Hopefully, you did the same, carefully checking your regexp generated
patches visually line by line, and compiling, and testing every driver
in this large patch individually.
I'm not a big believer in making trivial formatting changes and assuming
they work. Or that I didn't fumble fingers somehow. I've made many such
stupid mistakes over the years.
On Sat, 05 Dec 2009 22:00:41 -0500
William Allen Simpson <[email protected]> wrote:
> > You come out of nowhere as a new contributor. You have to constantly
> > ask about policy and other formalities wrt. kernel development.
> >
> Because they are not documented. Oh, and a reminder -- you've not
> answered my most recent questions....
Might I suggest a look at Documentation/HOWTO and
Documentation/development-process/? You might find that more of this
stuff is better documented than you think. If there are gaps, please
let us know where they are, and we'll endeavor to fill them in.
jon