Hi,
I also advocate a wiki but created automatically, like by a new script from utils. I think flashrom's supported hardware wiki page is a good example on how that could be done.
This script could open up a file in a text editor where one could check everything that works or not for this particular build, then the script would generate a table similar to those we have in most motherboard wikis, also including further details such as current Git tag, upload the current content of the config file, and so on. The text file would be stored in the current motherboard's directory, so it would be persistent.
Further on, the script could be enhanced to use mediawiki APIs to upload/update the wiki page of that motherboard and maybe even to add it to the mainboard support wiki.
What do you guys think?
Cristi
On Tue, Oct 11, 2011 at 8:27 AM, Marc Jones marcj303@gmail.com wrote:
On Sat, Oct 8, 2011 at 2:50 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear coreboot folks,
on IRC Rudolf mentioned that the A8V SE [1] works with the latest revision of coreboot and he asked if there is a way to tag that in the repository.
There are several ways to accomplish that but all seem to have down sides.
- Git tags. We could use `git tag <board name> <commit>` and interested
folks could then do `git tag | grep <board name>` to find tested revisions. Peter wrote, that Git tags could slow down the repository and that only finitely many tags can be used. Would the last point be a problem for us?
- Git notes. Peter suggested also to use Git notes. But Rudolf wrote he
finds it difficult to handle.
- Wiki. We could use the Wiki by either adding tested revisions to the
corresponding board pages or by creating a new page with a table. The first solution is not feasible because not all boards have their own page. Patrick wrote that using the Wiki often it gets out of date pretty quickly. Although in this case I think that would not be a huge problem considering that the noted revision actually was tested. Additionally not a lot of developers are comfortable using the Wiki. OpenEmbedded once did something like that [2].
- Provide tested images. In addition to specifying the revision such
tested images could be uploaded somewhere so users would not have to build it themselves. This would not work though, since the infrastructure is not in place and we have to be careful with images containing option roms(?).
- ROM-o-matic.net [3]. Idwer suggested a service similar to
ROM-o-matic.net where know revisions get build by this server and users can configure an image to be built. That is an interesting idea although it is probably the most difficult to realize. Could this be a GSoC project?
- File in repository. An other suggestion by Patrick and myself is to
put a file in for example `Documentation/working-revisions.mdtext` and note the tested revision and board there or to put a file in each board directory and note tested revisions there. The downside is that people would have to register with Gerrit to submit changes.
If we would manage our Wiki in our repository [4] options 3 and 6 could be combined.
- Messages to the list. Thinking about it the easiest solution would be
to create something like the script `alsa-info.sh`. This script collects the necessary information – in our case for example revision, boards, cbfs output, used build tools. Even better would be to run that script on the tested machine so also something like the tested distribution could be tested.
Then a mbox or text file with an appropriate name/subject line is created
[Tested] ASUS M2V-MX SE works with revision <commit>
which gets send to the list by the user or automatically.
People then can search the archive. The only downside is that a nice table is missing.
All in all I am quite surprised that no nice solutions seem to exist especially since I would imagine quality assurance (QA) folks in companies need to maintain similar data.
Please comment and add your ideas.
Thanks,
Paul
[1] http://www.coreboot.org/Supported_Motherboards [2] http://www.openembedded.org/wiki/Testing [3] http://rom-o-matic.net/ [4] http://www.coreboot.org/pipermail/coreboot/2011-June/065706.html [5] http://alsa-project.org/main/index.php/Help_To_Debug
Hi Paul,
Thanks for the writeup. I prefer option #3 and that this was information kept in the wiki somehow. It is searchable by the public at large. I would like to see us do a better job at the wiki as it is the public face of the project and the best place for new developers and users to get information. I like the idea of the maillist script. I think that would be great. With that, a wiki page or other html page could be easily generated. New users may not join the maillist but it is searchable by the public. Personally, I really don't like non-source files in the source repository. It is the most difficult place to find information and has a high bar to enter to get some simple information.
Regards, Marc
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot