2010/3/30 Andreas Jellinghaus <a...@dungeon.inka.de>: > Am Dienstag 30 März 2010 20:59:58 schrieb Martin Paljak: >> > i.e. if there are no active testers and developers for some plattform, >> > we should people know, even if opensc is in the ports collection or >> > something like that. for example debian doesn't upgrade opensc right >> > now, because it doesn't compile on debian kfreebsd. but we haven't >> > had any user from that plattform ever, and even for all *BSD I don't >> > remember any active user. >> >> If you look at the real distribution of users in the Windows/Mac/Linux/*BSD >> and combine it with the general availability or necessity of smart cards, >> then this is the expected result. Cant beat the statistics. > > lets say, again we should have some place to let people know what works > (was tested), doesn't work (got bug reports), or is unknown (no active > users / feedback at all). I see it more like white (known to work) and black (known not to work or known to work with documented issues) and gray (not known/obsolete/historic).
The goal is to maintain whitelists and blacklists and to eliminate gray, by categorizing it either black or white or deleting/retiring. Going down that road hopefully improves the situation, I'm using tags to categorize the drivers into supported/maintained/shouldwork/readonly/unknown/unclear categories. Why it is IMHO important to give black and white information? Otherwise it would be the U&D from FUD, which is no good for the receiver nor for the source of such information. The gray list can only be kept for a certain time. Seriously - GPK 8K is practically an extinct card by now. >> What should be done, is documenting exactly what we *know* that does not >> work and vice versa, to the extent that makes sense. Until somebody >> reports that it does not work on the Debian/kfreebsd, the fact that we >> don't know if it works is not really relevant. > > for the record: openct on debian kfreebsd doesn't compile. and all the > bugfixes etc. I send in for the debian package will not reach testing or > stable, until someone can have a look (or openct is somehow excluded from > kfreebsd, so it will be available at least on linux). OK, this means that for OpenCT it can be written "OpenCT does not support Debian/kfreebsd" in the FAQ/somewhere. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel