Date:	Tue, 6 May 2008 03:30:46 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	Remy Bohmer <linux@...mer.net>,
	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: Preempt-RT patch for 2.6.25

On Mon, 5 May 2008, Daniel Walker wrote:
> On Tue, 2008-05-06 at 01:47 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@...sta.com> wrote:
> > 
> > > I think dropping ports (temporarily) is perfectly reasonable. There is 
> > > no reason to hamper forward development just to keep old architecture 
> > > ports in the tree.
> > 
> > You are missing the point: a lot of people (those who wrote the brunt of 
> > the -rt tree and who maintained it over the years and who maintain it 
> > today) think it's not reasonable and have stated it very clearly to you 
> > that it's a bug. Keeping things alive is not preventing forward 
> > development.
> 
> That has always been my intention. I've never said the arch code would
> be permanently gone. 

Get it. Dropping it means bitrot.

The responsible maintainers keep that (maybe stale) code at least in
sync as far as the obvious fixups are concerned.

Your way of chosing the least effort approach and justifying it with
handwaving arguments is just disgusting.
 
> > Since it's code that you regard stale it shouldnt be all that hard to 
> > fix it up - in general it's much easier to fix a bug than to talk it out 
> > of existence, even if you disagree with a maintainer about how 
> > significant a bug is.
> 
> It shouldn't be hard, but it's too much to do all in one go. It's better
> from my perspective to do it in parts, given that there is significant
> refactoring to do per arch, if we solidify x86 then we can better
> refactor the other architectures. Better to do the split up once vs.
> many times.

Ah, it's too much in one go. But we should accept an "all in one go"
refactoring of the code we maintained over years including your
decision to drop fully functional ports (FYI, I've verified it) just
because you define that it's the best way to go.

Again, there is a choice.

1) Work with us - the maintainers and major contributors to preempt-rt -
   in a way which is useful for the project and the community

2) Hold on to your private "superior" uber queue and STFU.

> Not to mention this has not been discussed until now. My bisect tree was
> all but ignored until just recently.

It will be ignored for ever until you decide to work with us instead
of requesting that we drop our work in favour of your incomplete and
buggy hackery.

> > This issue is clearly not central to your refactoring (it cannot be, 
> > it's all about stale code), so by inflexibly insisting on your opinion 
> > against the (well-explained) opinion of the maintainers you'll just 
> > waste their time and make it more difficult for them to work with you, 
> > for no good reason.
> 
> I'm simply making sure their argument is widely known and potentially
> discussed on list instead of in a back room..

I'm impressed by your selfless efforts to save the world from the
ongoing preempt-rt conspiracy.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists