OK thank you Sichen Zhao. A brief message in the email body may be helpful next time to accompany patches.
I have some comments and others may chime in: * We prefer if you can send patches using git-send-email. https://devel.rtems.org/wiki/Developer/Git/Users#SendingEmail * diff.patch includes an autogenerated file. Please avoid adding those to your git. * We need to figure out how to deal with BSP-specific test cases. For now they tend to get put into the examples-v2.git. I believe there was discussion about how best to test the framework before using the existing infrastructure for testing a flash device, but I'm foggy on the topic. * Is diff2.patch all of Punit's original work, or does it include some of your modifications? * diff3.path include some random whitespace changes that should be avoided. Also, commenting out code in blocks is not ideal, especially without telling why the code has been commented out. This is especially important for shared code outside of a particular BSP's directory, as in this case of the eeprom driver. I would like to see a "clean" set of patches that builds from what Punit left off, and also a set of comments about what was fixed/changed and why. It would be best to create the patches using git-format-patch (or just git-send-email as mentioned above) in order to retain authorship information. Gedare On Mon, Mar 13, 2017 at 10:53 AM, Gedare Bloom <ged...@rtems.org> wrote: > This appears to be Punit Vara's patches for BB i2c. Possibly this is some > spam.. > > On Mon, Mar 13, 2017 at 7:24 AM, 赵 思晨 <zsc19940...@outlook.com> wrote: >> >> >> 发自 Outlook >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
