Might it also be appropriate to point out that some patches get directly applied to SVN, without any opportunity for mailing list discussion or review?
Or would that belong in a separate "process" document? This file seems to discourage a common style of development: cloning a development tree and then using a tool like "quilt" to develop a series of patches on top of it. That's significant, since few folk will have repository write access (really, only maintainers should) ... but those patches will be "patch -p1" style, not what "svn diff" produces. --- PATCHES | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/PATCHES +++ b/PATCHES @@ -2,6 +2,9 @@ Please mail patches to: [email protected] +Note that you can't send patches to that list unless +you're a member, despite what the list info page says. + The patch should be against svn trunk using an SVN diff. @@ -9,6 +12,10 @@ Attach the patch to the email as a .txt also write a short change log entry that maintainers can copy and paste into the commit message +(However, don't expect the maintainers to actually +include such entries in their commit messages if +they're longer than a single $SUBJECT line.) + Add yourself to the GPL copyright for non-trivial changes. To create a patch from the command line: @@ -25,4 +32,4 @@ http://svnbook.red-bean.com/en/1.0/re01. If you have a decent SVN GUI, then that should be able to create and apply patches as well... - \ No newline at end of file + _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
