Hi,
we desperately need a policy which states the exact requirements for listing a board or flash chip (or programmer) as known broken. This policy should include criteria for retesting as well.
The following is what I came up with. Comments appreciated.
Each known bad entry: - stores the flashrom revision used for the test - has a link to the mailing list post or mail address of reporter - has a reason why the board/chip does not work (e.g. chip region protection support incomplete, board enable missing, unknown) - is not a specific instance of a problem on another layer (e.g. do not list boards with chipset problems)
If a chipset/programmer/flashchip is not supported at all, don't list it.
If no effort was made to fix the problem, don't add an entry to the bad list because it wouldn't have any useful information.
Do not add entries to the bad list unless the current svn version of flashrom was tested (exceptions apply if current svn is broken).
After each release, ask people with broken boards/chipsets/flashchips to retest and update the bad entries with their new results, even if it's just that flashrom still does not work.
If the last known state of a board is older than one release (e.g. pre-0.9.0 for the 0.9.1 release) and the reporter does not respond, mark the board as unknown.
Reasons for the policy above: - Only track hardware where we have a chance to fix the problem. - Avoid accumulation of stale entries. - Give a better impression (loads of red with some green in between makes us look like incompetent developers). I noticed some press coverage about 0.9.0 where this was a problem. - Motivate people to contribute support for unsupported hardware instead of scaring them away with "doesn't work" if nobody didn't bother to add support yet.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger