> Thanks for your considerations regarding the name, that's a valid > point. Using some consistent scheme to differentiate the various types > is favorable, therefore using the model name instead of the company > name generally speaking makes sense. Also, I consider breaking > applications that use the CLI instead of libflashrom a good thing. We > should do that more often so that either they get so annoyed that their > authors review the libflashrom patches or annoy us back enough so that > we eventually integrate libflashrom. This was somewhat sarcastic, but my > main point is: the CLI should not be used by other programs. Regarding > users... that's an excellent point because I am not sure how well the > help texts (manpage and --L output) are after this change. Carl-Daniel?
Coercion, is always worse than the possible choices. To use the flashrom not need to be программистом. libflashrom requires C ABI compatibility. How to be with the integration of python, php, perl, ocaml, lisp, etc.? Who write for these language bindings, and will keep them up to date? A good practice in case of need to delete or change the name, is the creation of a new name as a synonym of the old, and the announcement of the old name as "deprecated". > Signing off is about the code, not about testing or reviewing. It > indicates that you were authorized to contribute that code under the > given license to this project. And in this case Carl-Daniel implies > with it general consent to what he has done with your code when refining > the patches. I interpret your considerations regarding the type > parameter as disagreement, but I might be wrong... I will sign an agreement with the license for this patch. _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
