[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl <ladis@linux-mips.org>]

On Wed, Apr 22, 2009 at 10:26:12AM -0400, Jerry Van Baren wrote:
> Wolfgang Denk wrote:

Dear Wolfgang,

>> Ladislav Michl wrote:
>>> That's perfectly understandable. I'm just trying to point out, that
>>> "design flaws can be fixed incrementaly, without breaking anything"
>>> attitude does not reflect reality. We break stuff and noone can test
> 
>> Please be fair. Re-read the whole discussion,  and  maybe  the  whole
>> mailing  list  archive.  Who  was  it  who claimed that this was some
>> (unwritten?) rule of U-Boot development?  It  is  very  difficult  to
>> defent  against malicious roumors like this, so I tend to just ignore
>> such accusations. Fact ist, they are just wrong.

"design flaws can be fixed incrementaly, without breaking anything" comes from
"...we should be doing ... poaching good ideas until we get to the point where
v2 can simply die" to which you replied "Full ACK". I know it was not expressed
exactly this way, I know you know there is and will be some breakage and I put
it into this light to get a clue *why* we should.
To quote Heiko:
| And I have hope, that this multibus design can be adapted for other
| subsystems too ... but somebody have to do this work, and if this
| is in v1, he has to do this for all boards!
My question was "why we shoudn't break it the way everyone knows it is
broken"? Ie. during v1->v2 transition, whichever way it happens. Just like
even/odd release numbering before linux-2.6 era. You may also read this as
an opinion of someone who is unrelated to Pengutronix and understands the
reasons behind the fork.

On 2009-04-21 14:40:04 GMT, Wolfgang Denk:
| What I missed, and what I  still  consider  a  big  chance  that  was
| missed, is any public discussion about such a new design - before the
| actual  work  was  started,  or  at  least  before  such  irrevocable
| decisions were made as not to consider any form of an upgrade path.

Whole this discussion proves that not discussing new design before showing
code was right decission... And now there is a new code we can look at
and we still should "poaching good ideas until we get to the point where
v2 can simply die" and yet noone pointed which of them are good ones and
if it is worth to go upgrade path. I consider that a big chance possibly
missed ;-)

And right, this leads to nowhere and I actually make mistake when writing my
first post to this thread.

>> Of course, board maintainers  are  supposed  to  regularly  test  new
>> versions,  and  ideally  provide  fixes  or  at  least complain about
>> breakage. Actually quite a lot of boards that cover a wide  bandwidth
>> of  different features and requirements *are* actually tested more or
>> less regularly.
>>
>> There are broken boards around, too -  of  course.  There  are  those
>> board  maintainers  who  simply dump their stuff on us and then never
>> show up again with any contributions any more.

Wolfgang, now please try to be fair to me - and I'm going to make it
personal - and show where I reacted slowly, overreacted or did anything
what prevented board I'm maintaining to be fixed in mainline. That code
was written in 2005 and now, four years later it is still broken. Perhaps
it is my fault that I do not stand pushing for more than a month at once,
but all this is simply far over my patience (I sent arm925t timer fix,
there was no reaction, but a document what I should measure. Gah... I sent
board fixes for .03, there were scheduled for -next (why the hell, it
touched board specific files only) and current code is broken again, so
sent another bunch of patches...). I did not simply dump anything on you
and I'm testing my code, showing in regular intervals and still cannot
push it into mainline. And to do it I have to ping relevant custodian
several times, whine on IRC and that all simply takes too much effort.
Pushing anything into kernel is much easier. And to be fair to you, I
know you can hardly do anything with that, but I couldn't resist and
took your last sentence personal.

>> I don't know how we could prevent that. It's probably happening  with
>> any similar software project. For exampole, do you think all exisitng
>> board  configurations  in  the Linux kernel are working, or even com-
>> pile-clean?

No, I didn't claimed that at all. It seems we are still missing each others
point, so I'm inclined to end that as you suggested above. Thank you.

> Note that this happens even worse in the commercial world: how many  
> printers were thrown in dumpsters because users bought a new computer  
> running Vista and the printer manufacturer couldn't be bothered to write  
> a new Vista-clean driver for the printers they had already sold?  They  
> just said "Sorry, buy a new printer."  That is a very obvious example,  
> there are tons of other examples.

Heh, fortunately we have source and fortunately there are printers supporting
postscript :)

Best regards,
	ladis