lkml.org 
[lkml]   [2009]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
From
Date
Hello Pekka,

On Sun, 2009-07-05 at 14:59 +0300, Pekka Enberg wrote:
> Hi Jaswinder,
>
> On Sun, Jul 5, 2009 at 9:02 AM, Jaswinder Singh
> Rajput<jaswinder@kernel.org> wrote:
> > On Sun, 2009-07-05 at 02:27 +0200, Ingo Molnar wrote:
> >> * Yinghai Lu <yinghai@kernel.org> wrote:
> >>
> >> > > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> >> > > +
> >> > > static int __initdata debug_print;
> >> > > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> >> > > +
> >> > > +
> >> >
> >> > two blank lines?
> >>
> >> ah, yes - i moved them around.
> >>
> >> > > +#define BIOS_BUG_MSG KERN_WARNING \
> >> > > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
> >> >
> >> > No user for this
> >>
> >> yeah. Mind sending a patch for these? (and any other things you
> >> might notice)
> >>
> >
> > But why you did this stupidity.
> >
> > I clearly specified that these are trivial clean-ups, if you found any
> > issue in the patch you should ping me. Instead of adding crap from your
> > side.
>
> What's with the attitude? It's perfectly okay for a commiter to change
> the patch as long as it's mentioned in the changelog. And that's
> usually much faster to do that for minor issues rather than ping the
> original submitter and wait for a resend.
>

I was also thankful to him but then he send me a long email and blamed
me that I wasted his 6 hours to do further cleanup and solve bugs and
other irrelevant things. And told me to not send further patches
otherwise he will ignore it.

He is doing mistakes and blaming others and misusing maintainer-ship.

You still thinks it's perfectly okay.

Thanks,
--
JSR



\
 
 \ /
  Last update: 2009-07-05 15:25    [W:0.196 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site