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