On Thu, Oct 11, 2007 at 12:17:12PM +0200, Wolfgang Denk wrote:
It won't work. At least not with a sane ammount of ressources.
With sane amount of resourcs you are thinking about your group at Pengutronix only, or about the whole community that stands behind U-Boot development?
I cannot speak for others here, but I don't think that our out-of- daytime-business ressources will be enough to go through the well known process for u-boot.
I, too, was thinking that getting rid of the old bitmask way for command selection or introducing a better config/build system was much too much effort on one side, and much to evasive for an evolutinary approach on the other side. Yet just a few months after initial discussion one has been completed, and the other is on the verge of being merged.
Did you have a look at the code yet? What is your estimation, how much effort could it be? I'm not generally against a gradual move, but I simply doubt that it will work.
There have always beeb unmaintained boards, that's true.
But most of the boards are in a pretty good shape with mor eor less active maintainers behind them who *do* test the code.
My experience is that board vendors tend to make it once and then forget about the whole think, because they have something they can sell with their products. But it may be just a personal experience, based on the part of the market we serve.
create a sane code base for the infrastructure (almost done) and do the designs right
migrate boards over to v2 when they have to be touched anyway. For a single board it is easy (but surely will uncover deficies in 2), which may need further steps in the infracturcture).
I tend to disagree here. It may work for many pretty basic ports. But for any "real" projects like what we're seeing in our everyday work too many essential features are missing.
Can you outline which ones?
OK, you will argument that this is a good chance to port these into the new code - but we neither have time nor resources to do that on our own, and we cannot easily sell this to a customer when the same features are available for free in the context of the existing code.
Our top priority is source code quality and maintainability. "Features" has never been a negative argument with the v1 code.
And I can once again encourage everyone to have a look at the code and outline what is really missing. In the end, this is Open Source, and with v1 we have a very feature rich code base to gain synergy effects from.
We have done the first business critical projects with the v2 codebase. Our experience is that it doesn't take more time to make a board support package than with v1, at least not for the "standard case". So there is nothing really "extra" which has to be sold. Again - this is from the perspective of our projects, which is mostly SoC based.
And it surely doesn't mean that everyone has to step to v2 at once. In fact, there's nothing speaking against v1 and v2 coexisting for quite some time.
Agree. Time and community will decide.
If we can agree on that, I'm fine.
Robert