From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 12 Oct 2012 12:11:17 +0200 Subject: [U-Boot] U-Boot git usage model In-Reply-To: <1349981971.6903.16@snotra> References: <20121011191658.43a0df72@lilith> <1349979213.6903.11@snotra> <20121011204502.54331c88@lilith> <1349981971.6903.16@snotra> Message-ID: <20121012121117.3311b3d2@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Scott, On Thu, 11 Oct 2012 13:59:31 -0500, Scott Wood 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 > > 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 . > -Scott Amicalement, -- Albert.