On 10/12/2012 05:11:17 AM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 13:59:31 -0500, Scott Wood scottwood@freescale.com wrote:
On 10/11/2012 01:45:02 PM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood scottwood@freescale.com wrote:
FWIW I think putting policy documents in a wiki, without any guidance on who's supposed to edit it or how changes get
approved,
is a
bad idea. Why not put policy documents in the git-managed
source
tree? And changes would be proposed, discussed, and accepted/rejected like any other
change.
Plus
there'd be at least a chance of a commit message showing
rationale.
While I can see the benefits you find in this, is it not based on the unspoken axiom that the project's policies should necessarily
be
subject to a democratic process?
Process is othogonal to revision control. We could vote on whether
a
policy patch gets applied, though I do not think U-Boot is currently democraticly run, except to the extent that Wolfgang sometimes
changes
his mind if enough people complain. I do not know of any existing democratic process for approving a wiki update, and would hesitate
to
just go make a change.
My remark was that Stephen took the democracy for granted in the process, not that there was a relationship to be drawn between process and revision control.
OK, I misread what you said. I don't think my comment (I assume you meant mine and not Stephen's, given what it's a reply to) assumes any such thing. Wolfgang is free to NACK any patch that changes policy in ways he doesn't like. With the wiki it's not clear who should make changes to policy documents and under what circumstances, but it doesn't appear to be just Wolfgang, as he has said things like "it's a wiki, go edit it".
http://www.mail-archive.com/u-boot@lists.denx.de/msg87395.html http://www.mail-archive.com/u-boot@lists.denx.de/msg12795.html
As for the merits of the policy itself, I find maintainer signoffs
to
be useful, for example to distinguish a patch that I've applied
locally
versus one that I've fetched from upstream.
This you can see by looking at the upstream branch tip, the patch's committer identity or by doing a git branch -r --contains <commit-id>.
Sure, I was just describing a way in which I found it useful. Are there any benefits to U-Boot's current policy that justify deviating from what Signed-off-by: means in Linux?
-Scott