Hi,
in message 8039970AF146314597457D3B51A68B382E0429@cossmgmbx02.email.corp.tld you wrote:
This is a good opportunity for me to trot out a thought I've been thinking
Actually it is not. You are a couple of weeks early.
Now I have to explain a few ideas in the public which I rather had more time to think about internally.
for a while, but have not been able to put together as a cohesive proposal. It would be nice, and the new wiki makes it achievable, to have a feature list where people could identify what whas available and what they felt were the best features (and which implmentations should be steered clear of) which would serve as guidance for newcomers. Some of this information is in the README file, but it is hard to keep up to date and tends to not warn of lesser implmentations nor point out good implementation.
I agree.
Before the wiki, it would have been impossible for one person (Wolfgang) to maintain.
With the wiki, it still may not work, because people may not contribute and there is a risk of people getting into "my implementation is better than your implementation" fights. Hopefully we are all smarter than that.
When we decided to use a wiki it was one of our intentions to allow board maintainers to take care about the documentation for their own boards.
Another problem is organization: should we organize by processor and board (which is intuitive but not necessarily the best for looking up information) or by feature (flash type, ethernet interface type, SDRAM type, etc.), or by both? Probably both of the above :-/.
The setup as is now is organized by boards. This may be non perfect in all situations, but I am convinced that everything else would be worse.
Perhaps we can start a wiki documentation branch by having each board maintainer make an entry for their board in a list, branching to a short description of the board and a list of the features. The list of features could then branch to a description of that feature, many of which would be shared by several boards as they use the same driver.
Please wait a bit.
There currently is a board selection box in the DULG wiki http://www.denx.de/twiki/bin/view/DULG/BoardSelect but it only has two boards listed and displays the Denx documentation, not really what I have in mind. Also, I am thinking more of a whole page list
Wait, wait, wait.
What you may have missed, and what is not directly obvious, is the fact that this "DENX documentation" actually uses a constant text framework (which is augmented with a lot of conditional text modules) and a set of include files. The include files contain for example all the examples in the document. These include files are automatically generated when we run our regression tests for U-Boot.
The idea is: you build a new version of U-Boot, you run the regression test suite, which not only tells you if the new version is working OK, but which also automagically creates a new version of the documentation which matches EXACTLY the code that has been running on your board...
The problem at the moment is that our regression test suite (a set of TCL / expect scripts) is not in a state which I would like to proesent to the public; also it is much too painful to add support for new boards.
We are working on a better solution.
Once this is ready, everybody (not only a board maintainer, but really _everybody_ who cares) will be able to set up and run the regression tests for his own board, and (if he wants) submit the test results to the wiki.
This would allow for a lot of nice features:
* You will be able to see which version of U-Boot was the last one running successfully on a specific board.
* Problems in a specific implementation will show up more easily - we have a pretty well-equipped test lab, but we cannot nor do we want to test on all existing boards ;-)
...
You may also have noticed that we took over maintenance for the orphaned Embedded PowerPC HOWTO file. It has been converted into a wiki, too. I can easily imagine to merge both resources into a more general document. I can imagine to give hardware vendors an easy way to enter their U-Boot / Linux capable hardware into this documentation system. Of course maintainers of code (U-Boot, Linux, additional packages, ...) could enter their information there, too.
Now the problem is, I'm not that familiar with the Denx wiki (sorry, Wolfgang, I just haven't had the time to crawl through it) so I don't know if I'm proposing something that already exists. If it doesn't exist, I
Nothing exists in a working state, but we have some plans that target into a very similar direction.
don't know the best place to splice in my proposal. Also, the proposal will only be successful if most or all the board supporters kick in some effort.
Actually no. My idea is to provide an easy mechanism so that every- body who cares can contribute, and those who don't want just don't. If somebody checks and sees that board XXX has been verified to run the latest version of U-boot just a couple of days ago, while the last successful test of board YYY is 2 years old, and test resutls for board ZZZ have never been submittet at all this too gives some valuable information about the quality of community support for these boards.
Arghhh... Sorry, I probably missed many things we have been discussing internally. Detlev, maybe you can fill in some more of this?
In any case - these are just ideas. Some of this is under work actually, but please do not expect to see something ripe for distribution soon.
Best regards,
Wolfgang Denk