[flashrom] [RFC] Bad chips and boards policy

[Carl-Daniel Hailfinger]

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

-- 
http://www.hailfinger.org/