[U-Boot] U-Boot git usage model

[Scott Wood <scottwood@freescale.com>]

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 at lists.denx.de/msg87395.html
http://www.mail-archive.com/u-boot at 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