[U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 13:59:31 -0500, Scott Wood
<scottwood at 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 at 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.

> 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>.

> -Scott

Amicalement,
-- 
Albert.