On May 8, 2009, at 10:06 AM, David Brownell wrote:
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?
I'd rather we stop that from happening. It sidesteps the community review process, introduces more risk to trunk, and means we get long, heated arguments about the changes rather the discussion. The list should be a clearinghouse. A lack of comment shouldn't imply consent.
Or would that belong in a separate "process" document?
It's not appropriate for the PATCHES file per se, but we should formalize the process for _after_ a patch has been sent to the list. That is mainly for maintainers to reference and for submitters to understand what is happening.
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.
My main concern is that I can save the patch to disk without my mail client mangling it and that I can apply it with a simple command. If there is a chance it ends up being -p1 instead of -p0, I don't really care. I just want a text file that generates patch-compatible diffs as an attachment to the email.
Of course, that's just my opinion. As everything else in this project, we should do what the community wants.
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
