Re: Preempt-RT patch for 2.6.25

[Daniel Walker <dwalker@mvista.com>]

On Tue, 2008-05-06 at 12:32 -0400, Steven Rostedt wrote:
> On Tue, 6 May 2008, Daniel Walker wrote:
> >
> > As I've been saying, had you wanted the architectures included, you
> > should have said that a month ago. You had a month you review everything
> > and work with me ..
> 
> Daniel,
> 
> Don't give me this "wo is me" crap.  After you posted the series I replied
> asking that you prove that it doesn't do any changes to the actual code.

You said "byte for byte identical". I assumed when you reviewed the
changes you would see it wasn't changing anything.

> http://marc.info/?l=linux-kernel&m=120761484315539&w=2
> 
> But you admit that you didn't do that yourself. This is also the time that
> we were very busy at working on ftrace and hoping it would make it into
> 2.6.26 (which it did not). Remember our goal is to get as much as possible
> into mainline Linux. And getting something from -rt (ftrace) into Linux
> was the higher priority for me than to go review your series after you
> tell me that you dropped archs and made changes to the code for the sake
> of bisectability.

Who am I to dictate priorities to you? However, that's no excuse for
ignoring something important.

> I thought my response was good enough to give you a clue that you needed
> to show that your work didn't make any changes. Making the tree bisectable
> is a "clean up" not a code design. And with all clean ups, they should not
> cause any changes to code behaviour. You've been doing kernel development
> long enough to know this. I'm not about to hold your hand and step you
> through the proper process of getting things accepted.

Setting a requirement of binary compatibility is un-reasonable. I told
you it wasn't making functional changes, that combined with a concerned
review of the code should have been enough.

> If you don't make an effort to work with the maintainers instead of just
> shoving out a bunch of code and expect us to do the dirty work to make
> sure its ok, then you might as well give up. Take a lesson from Gregory
> Haskins. He came out with a lot of changes that were controversial at the
> time. Instead of shoving his code down our throats, he took our critisms
> seriously and worked hard to work with us. Now most of his code, even the
> controversial parts, has been incorporated.

You have a responsibility as a maintainer .. You have to at least look
at code, and decided exactly how to handle it. You have to decided how
you want to merge the code, and when to merge the code.

Bisection is not an optional feature. It's default acceptable, and it
should have been first on your merge list. 

Instead you didn't want it. You default rejected it. From my perspective
not wanting to merge something like that is itself unreasonable.

How is discussing this shoving my code down your throat?

Daniel