Paul, I want to apologize for my mistakes and hope that I did not cause everyone a lot of time and effort on clean up. I will review the necessary documentation and follow the guides provided.
Thanks for pointing out the errors, Kent ________________________________________ From: Paul Fertser [[email protected]] Sent: Saturday, September 20, 2014 12:48 AM To: Kent Brinkley Cc: 'Andreas Fritiofson'; [email protected] Subject: Re: [OpenOCD-devel] Help pushing a patch Hello, On Fri, Sep 19, 2014 at 03:32:54PM +0000, Kent Brinkley wrote: > You are correct, fat fingered it, check-in complete. Thank you for your work and I hope for a fruitful collaboration, proper vendor support is always a good thing to have both for the users and for the IC vendor. However, all of your submissions are not directly applicable, please try to follow HACKING more closely. The main issue is that when you are offering a patch series, you're supposed to simply have a local branch that you push to Gerrit. Then each single commit of that branch will be handled as a separate change by Gerrit but it'll show the commit parent(s) in "Related". Each patch in series should be fully cleaned up and consistent, and in the correct order. It's usually easy to do with "git rebase -i". All checkpatch errors are easy to spot before actually pushing to Gerrit, as per instructions in HACKING you are supposed to "run tools/checkpatch.sh to verify your patch style is ok". When you push a new version of an existing patch you must keep Change-Id line intact (it happens automatically if you simply amend the commit without removing that line), that will make Gerrit create a new version of an existing change. Also, please try to follow the rules for the commit messages: topic: Short comment <blank line> Longer comments over several lines, explaining (where applicable) the reason for the patch and the general idea the solution is based on, any major design decisions, etc... Where topic in your case would be something like "target/mips32". It would also be nice if you mentioned regression-testing results on different targets (such as microchip mips32, broadcom mips, etc) when touching potentially sensitive code, and my impression is that most of the MIPS code in OpenOCD can give one unpleasant surprises. Please also take into account running OpenOCD on big-endian hosts, live-testing MIPS there would be much appreciated. Thank you in advance! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
