From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 11 Oct 2012 13:59:31 -0500
Subject: [U-Boot] U-Boot git usage model
In-Reply-To: <20121011204502.54331c88@lilith> (from
	albert.u.boot@aribaud.net on Thu Oct 11 13:45:02 2012)
References: <20121011191658.43a0df72@lilith> <1349979213.6903.11@snotra>
	<20121011204502.54331c88@lilith>
Message-ID: <1349981971.6903.16@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

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.

-Scott