[coreboot] [RFC] Tracking run tested coreboot revisions for boards

[Marc Jones]

On Sat, Oct 8, 2011 at 2:50 AM, Paul Menzel
<paulepanter at 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.
>
> 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