On Sat, Oct 8, 2011 at 2:50 AM, Paul Menzel <[email protected]> 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. > > 1. 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? > > 2. Git notes. Peter suggested also to use Git notes. But Rudolf wrote he > finds it difficult to handle. > > 3. 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]. > > 4. 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(?). > > 5. 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? > > 6. 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. > > 7. 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 -- http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
